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.
We need to take into account the real start of the capture to
land the ticks in the right position. Add "epoch" concept
to SpVisualizerTicks for just this purpose.
This is copy/paste from PnlMultiPaned. The feature we want from
it is the ability to resize paned halves based on their natural
sizing up until the user has manually changed the paned handle
position.
When we find ourselves on a HiDPI display, we need to make sure
we setup the device scale factor properly and adjust our render
checks for valid surface sizes.
Generally we want this thing hidden, so only show it if we have
zoomed in enough to cause it to be useful.
We need to also find a way for the container to be able to
handle the change in size request and adjust the GtkPaned
to be non-ugly.
We don't want to cache all the datapoints from the underlying
capture, just the datapoints for the visible region (and some
at the edges so we get proper cairo_curve_to() x,y coordinates).
This isn't a major optimization yet until we start supporting
much larger capture sizes. But that will mostly be improved with
capture indexes anyway.
There are lots of little things that need fixing, such as the
ticks positioning, and reusing surfaces as much as possible, but
this gets our "MVP" panning in place.
If we don't have a minute worth of input, we should shrink the
visible area to exactly what we came across.
We still have the issue of the UI creating the capture file
before auth has completed, but we can fix that later so we
have a "semantically" correct start time.
These signals are emitted when a visualizer row has been added
or removed from the view. This might be handy if you want to
resize a paned based on the natural size of the visualizers.
This adds a new helper widget SpVisualizerView to simplify using
visualizers from applications using libsysprof-ui-2 such as
Builder.
We can manage the view range, zoom, etc from this widget going
forward.
We need a simple helper to choose colors for visualizers so
they do not overlap. This is just a simple cycle using some
predefined colors.
We should come up with something more unique in the future or
possibly do this with CSS and :nth-child(n) once we have access
to CSS nodes.
