I think this was masked by the .destructive-action class being defined
later in the Adwaita CSS than the .suggested-action class, so its values
for each property win.
Re-opening the FD on every poll is pretty expensive. So we should avoid
doing that as well re-use the read buffer (page-aligned, <=1 page) for
the sample data.
The point of this file was to be easily usable by applications that want
to generate capture files (or proxy them). The intention here is that we
only have SpCaptureReader/SpCaptureWriter (and associated bits necessary
to support that).
This makes sure that we do not use GObject from the libsysprof-capture-2.a
while still having GType's in the libsysprof-2.so dynamic library.
We also invert the GObject macro check so that the default is to not
register a GType which increases the chances that copy/paste code does
not run into double-registering a GType if used with an application that
links against libsysprof-2. (One such example could be if Gtk uses this
code for timers, as it would break Sysprof itself).
This currently isn't installed, but it is useful for joining streams
together when working on sysprof data acquisition. We may want to install
it at some point in the future.
sysprof-cat file1 file2 file3 > out.syscap
This reveals that we've got really bogus times from these events. I
think there are two things here: the begin is the submit time, not the
submit-to-hardware time. And the end time is retire, which is too
delayed to be really useful. We need to move i915 over to the
low-level tracepoints.
However, this code proved to be useful for vc4, where I have good
timings.
Max uint was more than we allow, since we steal the top 8 bits for some
other data. This instead checks for 24-bit and warns if the user tries to
store a counter value that was not registered.
This isn't really meant to be distributed as a flatpak, being that we would
want to have a daemon available to get anything done. But it does make it
easier for people to open Sysprof in Builder and hack on things.
We have an annoying issue where we look at all fiends of a counter values
chunk in the counter set frame. So we need those values set to zero. If
we are passed fewer counter values than can fit in the frame, we leave
some of that data uninitialized. This ensures that it is cleared.
This will help make sense of vblank events in a multi-screen
environment (where there are two streams of vblanks), and hopefully
also useful for correlating to compositor events.
