| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This partially reverts 2edbda252619b.
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.
|
|
|
|
|
|
make libwidget independent of libcanvas.
Confine basics to pbd and gtkmm2ext.
|
|
Initial use is for the WaveView class to determine whether on not to draw the
waveform in the GUI thread.
|
|
|
|
intersect
Refactor GtkCanvas::request_redraw to use Rect::intersection
|
|
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.
|
|
Emitted by the canvas immediately before rendering.
|
|
|
|
|
|
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
|
|
|
|
This allows to re-use the concept with CairoWidget
|
|
|
|
Special case Ardour's Canvas NSView to forward gdk-events
which are otherwise special-cased to read AU-views..
|
|
This avoids Coregraphics (cairo_quartz_surface..) competely.
The openGL texture bypasses CG's slow argb_image and CGSColorMask
methods.
|
|
Once upon a time there was a beautiful Apple tree in palace of
GtkAnkhAmun in Cairo...
|
|
|
|
boost::optional from Canvas
|
|
from Canvas
|
|
Rect::empty instead.
This commit includes Rect::operator bool() which might be a candidate for removal in a future commit, in an attempt
to make the meaning clearer
|
|
concrete instances to supply a Pango::Context; do this for GtkCanvas and Push2Canvas
|
|
|
|
Patch taken (and forward-ported to HEAD) from
<https://anonscm.debian.org/cgit/pkg-multimedia/ardour.git/plain/debian/patches/0100-fix-typos.patch>
|
|
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.
|
|
|
|
|
|
Paul Davis was responsible for introducing almost all of this.
|
|
|
|
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.
|
|
They need to use fractional coordinates, and the border position needed
generalizing for other border widths. See verbose comment for details
|
|
|
|
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.
|
|
need to inspect root group children to find them
Conflicts:
libs/canvas/canvas.cc
|
|
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.
|
|
Looks like a guaranteed else branch to me, but who am I to argue with gcc?
|
|
|
|
|
|
|
|
|
|
and include background fill
Conflicts:
libs/canvas/canvas.cc
libs/canvas/canvas/canvas.h
|
