| Age | Commit message (Collapse) | Author |
|---|
|
|
|
'gtk2_ardour/gui_thread.h'
Technically it doesn't make much difference but from what I can tell, the only files which #include 'gtk2_ardour/gui_thread.h' are the source files from gtk2_ardour itself. The support libraries always #include 'gtkmm2ext/gui_thread.h' directly (which seems sensible). So for consistency's sake, let's keep it the same for libcanvas.
|
|
Invalidate all source entries from the image cache when we get our
region's DropReferences signal, while ignoring any subsequent regions with
no source.
|
|
Should fix crash when audiosource disappears.
Reworked from submitted patch from tlat.
|
|
|
|
|
|
|
|
Fixes bug #6179. Top vs. bottom seems pretty arbitrary to me, and this solves
the obscuring issue (which is quite common since there are often PC events at
the start of MIDI files), so bottom it is.
|
|
In summary:
* no antialiasing of waveviews
* no diagonal lines
* simplify clip detection
* don't use LINE_CAP_ROUND for outline
* use the wave colour when drawing outline only
|
|
wasn't the no-op it claimed to be.
|
|
|
|
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.
|
|
Canvas::WaveView
And add commented out attempt at more subtle attempt to get it right
|
|
remove TimeRectangle
|
|
|
|
waveview when necessary
|
|
They need to use fractional coordinates, and the border position needed
generalizing for other border widths. See verbose comment for details
|
|
This is required to be able to draw precise single pixel lines, as described
in the Cairo FAQ
|
|
|
|
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.
|
|
position of the group.
They also do NOT need to consider scroll offset
|
|
need to inspect root group children to find them
Conflicts:
libs/canvas/canvas.cc
|
|
fixes http://tracker.ardour.org/view.php?id=5589#c15515
|
|
operation is undefined. C works on all platforms
|
|
This reverts commit 8f823388d9bd5aa8e297ab05be8c9fb323518945.
|
|
|
|
The problem this is avoiding makes absolutely no sense. Either I'm dumb, or
something is more deeply wrong with scroll group bounding boxes, or both, but I
don't care anymore. This works. Viva release mode.
|
|
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?
|
|
|
|
Time to move away from rgba macros
|
|
returns accurate visibility
Child items will be hidden when their ancestors are hidden. The old ::visible() implementation didn't reflect this. In addition,
when changes are made to hidden items (new definition of visible/not visible), don't bother to request redraws, since this will
be done when the item becomes visible again.
|
|
|
|
|
|
|
|
|
|
|
|
apart again
|
|
Also, use a slightly off-white rather than pure white, which should really be configurable
|
|
|
|
Q: is bounding_box(); etc more complex than queuing draw?
either way, canvas should eventually switch to
use an optimized OptimizingLookupTable.
|
|
|
|
|
|
|
