Overview of changes in Sysprof 3.22.1
=====================================
Changes since 3.22.0
* A new data source called "hostinfo" has been added. It records various
CPU datapoints as "counters" in the sysprof capture.
* A new visualizers abstraction has been added so that we can start
providing new ways to look at profiler data.
* A CPU visualizer has been added which renders datapoints recorded
from the hostinfo data source.
* Selecting ranges of the visualizer will update the callgraph limiting
stacktrace samples, to the given time range.
* Missing headers are now installed which may be needed by applications
using libsysprof-ui.
* A keyboard shortcuts dialog has been added.
* A theme manager has been added to allow us to provide custom CSS for
various themes. Currently, we have additional styling added for
Adwaita and Adwaita-dark.
We want this in sysprof.h (without UI components) so that we
can use it to filter things in profilers. Therefore, we don't
need to make it namespaced to "visualizers" since a time range
selection is a fairly straightforward, and non-UI confined
implementation.
So that Builder can depend on our recent visualizer work, we
can bump the version now here. We will release 3.22.1 before
too long anyway, so its fine to bump the number now and just
update news/tag for release.
These have the chance of being dropped unless we export them
here manually. We probably should change how we export symbols
so this isn't required in the future.
It is important that our capture current time matches the
same clock we are using for events. Otherwise we could have
drift between CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW.
This allows us to use the selection in profile components
without the use of Gtk.
We will probably end up renaming this class to SpSelection or
something like that.
We want to set some custom backgrounds for the visualizers, and
those need to track with the current theme. SpThemeManager will
watch the systems theme changes (including dark theme) and
update the loaded CSS resources as necessary.
If we have a scrolled view, we might be a bit off on the
selected range until this commit. This adjusts for the scrolled
area and ensures that both ticks and selections land in the
right place.
This gets started on allowing the user to select a region.
Nothing is yet responding to the changes in selection, but
that can come later.
Ideally, we will truncate (or mark rows invisible/insensitive)
if they do not fall within the selected time region.
This uses the graph_width to get the proper time range of the
visualizer row. Mostly, this is just complicated because we
the ticks to be an overlay rather than inline with the list
rows.
We can avoid using the inline scrollbar in favor of overlay
scrolling if we bridge the adjustment into the GtkViewport.
This sadly requires us to subclass things to get it just
right.
If we are at the beginning of a capture, we would end up drawing
the msec because h/m/s were all zero. Make sure we also have a
non-zero msec or just fallback to regular timestamps.
When changing the zoom (zooming out), we could potentially
let the scrollbar be past the end. This looks pretty bad when
the GtkWindow doesn't clip correctly.
This just adjusts things so we push ourselves back into the
visible area.
Because we are using ListBox, we can't quite do scrolling the
way we'd like (naturally using the scrolled window). So for now
we need to just disable hscrolling here.
However, it would be nice if we could teach the viewport to
handle this correctly so that it wires up the
GtkScrollable:hscrollbar-adjustment to our internal one.
This adds label text next to important epochs. We determine
which epochs are important by trying to choose the waypoints
that had more than 2 epochs land in view.
This avoids showing numbers for multiple time-spans, but giving
enough context to be useful.
This is overactive because we could be zoomed in so far that we
don't pick up the adjacent frame. We need something more clever
that can pick up frames adjacent to the visible area of the
capture.
