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.
Mixbus in particular uses both types of tooltip so we might as well make them look the same.
N.B. The appearance is fine now on Windows but needs to be tested on the other platforms (i.e. some tweaking might be necessary).
All canvas objects share just one tooltip object which is based around Gtk::Label. The Label expands if the current tooltip text is wider than the previous text. However, it doesn't shrink again if the next tooltip has shorter text. Eventually, this results in some very strange looking tooltips (especially in Mixbus where they're used quite extensively).
Deleting the object after use will force a new object to get generated next time (at the correct size). There's still only ever one object per canvas but it's no longer persistent.
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.
The region is the un-coalesced set of rectangles that were requested for redraw. The area
is the coalesced single rectangle. In the worst cases, the coalesced rectangle could span
the entire window even though just two pixels in opposite corners were to be redrawn.
There is a problem with the verbose cursor as it is dragged across MIDI tracks. TO BE
FIXED.
Achieve this by adding a new hscroll group just for cursors.
That requires a slightly smarter window_to_canvas() to deal with overlapping
sensitive scroll groups. New rule is that scroll groups can overlap, but the
most sensitive one found from the top down will be chosen to translate
coordinates. This basically means don't overlap scroll groups with different
sensitivities.
In the presence of scroll groups, having a canvas-wide window_to_canvas()
and/or canvas_to_window() fundamentally makes no sense. At some point in the
glorious future we should kill those and use only item-relative coordinate
translation.
Search scroll groups for event delivery from top to bottom rather than bottom
to top. Overlapping scroll groups still aren't properly supported by the
canvas, but currently all we care about is that the top one gets the event, so
the hscroll group (tempo lines) can be below the hvscroll group (tracks), but
the latter gets events.
