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
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.
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.
Items call ::queue_resize(), which sets a flag in the canvas; at next idle, we call
Canvas::layout() which walks the item tree and recursively calls layout (depth first)
on all items needing a resize.
Only Container types implement layout, and so far only Box
This partially reverts 2edbda2526.
Using cairo-groups increases performance on MacOS, and retains
retina-resolution.
However it adds a performance regression for MS Windows graphics
rendering. cairo-groups use a "similar" surface, not an image surface.
Empirically this adds significant overhead compared to rendering
using the CPU and using bitblt.
For MacOS/X this is equivalent, rendering happens using a
CGBitmapContext + image-surface. Windows and Linux needs profiling
for respective equivalent surfaces.
This is an intermediate commit, before replacing image surfaces with
cairo pattern groups.
The eventual goal is to reduce flickering and/or use
CPU + bitblt for specific widgets instead of cairo
graphics-cards accel.
This also removes excessive calls to getenv() for every rendering
operation.
Called when an item has requested a redraw and intersects with visible
canvas area.
Also add Canvas::prepare_for_render that will call Item::prepare_for_render for
items visible on the canvas.
Various GdkEvents are not yet handled correctly, eg. unpacking a widget
from its container does not unmap it, nor are remaining widgets in the
contained re-positioned (size allocation does not change, nor does the
mapping). This affects eg. Mixbus Strips
Backport from Mixbus. In Ardour this does not currently matter
since there is no top-level canvas destroyed top-down.
...
Editor::session_going_away
MixerStrip::~MixerStrip
MixbusStripCanvas::~MixbusStripCanvas
ArdourCanvas::GtkCanvas::~GtkCanvas
ArdourCanvas::Canvas::~Canvas
ArdourCanvas::Root::~Root
ArdourCanvas::Container::~Container
ArdourCanvas::Item::~Item
ArdourCanvas::Item::clear_items
GtkCanvas::item_going_away()
queue_draw_item_area()
..expose can take place async to garbage collection: crash in one of the
items.
Gtk coalesces multiple exposes into a single combined rect.
If _single_exposure is disabled, we break apart the individual expose rects for the canvas rendering.
Paul Davis
Robin Gareus
Tim Mayberry
Ben Loftis
David Robillard
John Emmas