Note that this implementation only redraws a single (cairo_rectangle_t-defined) rect, and cannot
provide sub-rects the way that a normal GDK/GTK expose-driven redraw can
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
> This group functionality can be convenient for performing
> intermediate compositing. One common use of a group is to
> render objects as opaque within the group, (so that they
> occlude each other), and then blend the result with
> translucence onto the destination.
https://www.cairographics.org/manual/cairo-cairo-t.html#cairo-push-group
The main use case where will be to render opaque layered
[MIDI] regions transparently onto a grid.
This is never for inline references to parameters, only for starting parameter
documentation blocks. The "@p" command is for this, although unfortunately
Doxygen doesn't actually do anything with it and it's just an alias for code
text.
If queue_draw is "frozen", we simply accumulate drawing
requests in a (union) rectangle, and when finally "thawed"
the canvas submits a single redraw request for the entire
accumulated rect.
Although in theory this is all that GTK/GDK does for
draw requests, callgrind reveals significant costs
associated with the actual calltree for GtkWidget::queue_draw_area().
One potential cost is that GDK also maintains a list of
invalidated rectangles in addition to the union, and
for MIDI regions with thousands of notes, this can represent
real overhead. This approach dispenses with the rect list,
since our Canvas drawing model only uses the union rectangle
anyway.
The AudioClipEditor features a scroll bar that is a part of the canvas. Because scroll
groups are at the top level of a canvas, the scroll bar is necessary within a scroll
group, which causes it to get confused about the difference between its own
position within the canvas and that of the scroll group. This commit introduces
a per-Item flag, _scroll_translation, which is true by default. If false, the
item will not have coordinates translated to reflect scroll group position.
We need to be able to construct Metrics after the ruler is constructed
in order to deal with Triggers which are potentially short-lived. We
stored the reference as a pointer anyway, so it's not as much of a change
as it appears.
If there's a grabbed item (GtkCanvas only at present) then unless it belongs to the scroll
group used for scroll offset translation, the event coordinates should not be translated,
even if the mouse pointer moves into the scroll group.
