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 reverts commit 37cae2f971.
This changes causes issues with recursive calls to the enter/leave event handling
stacks in gtk2_adour. Semantically, the change makes perfect sense, but finding
a solution to the recursion is challenging.
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 tooltip should remain visible until the mouse leaves
the item's bounding box. Also do not start the tooltip
timeout if the item does not have a tooltip.
On Intel systems ArdourCanvas::COORD_MAX (1.7e+307) was rounded
to (gint) -2147483648. gtk+ treats negative window size-requests
as 1px.
However on ARM, COORD_MAX was truncated to +2147483648, gtk+ limits
this to 65535. Most WM/Xwin systems cannot handle windows this large.
It also exceeds the max size of cairo [image] surfaces.
This issue was introduced in a1c67b4ad7
when "natural_size" was removed. Before that change infinitely large
canvas had a natural_size of 2x2 px.
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.
This means that a request to (re)draw the Rect (0.5,0.5,9.5,9.5)
will actually generate an expose event for (0,0,10,10)
Note: the above rects are of the form (x0,y0,x1,y1)
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.
