Replaces the list of points in TempoMap with TempoSection functions, which
compute tempo-at or tick-at time relative to tempo section start.
TempoMap consults them additively to determine things like bbt_time(),
frame_time() get_grid() etc.
This has a marked effect on scrolling speed along with the code simplification
in the places it has been attempted.
Several things are broken here.
Currently every ramp except the last one is an exponential ramp. this may
be simple to fix :).
Mouse-over midi grid doesn't match mouse click grid. should also be simple.
Many things seem to work, but their accuracy should be in question until
each area has been addressed.
uselib is no longer implicit (inherited by .use). This is still incomplete,
some uselibs for non-linux variants may be missing.
bld.is_defined("HAVE_XXX") also no longer works and will have to be
changed (I think to bld.env["HAVE_XXX"]) in countless places.
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.
There is a highly unlikely case where the render thread can have zero
requests in the queue, but it is not supposed to be terminated.
1) WaveView::queue_get_image();
wake up thread, *but* the thread does not start yet
2) WaveView::cancel_my_render_request();
and now the thread starts.
1,2 are initiated by user actions from the GUI thread and are normally
orders of magnitude slower than scheduler-thread wakeup.
Use gdk_pango_layout() for all text-size calculations.
In Canvas::Text always use the same context (local image surface)
for layouting (prior to this, local and window-context mix resulted in
different sizes).
To avoid pixel jitter, the top and bottom of each line in the waveview must be computed together in a single computation,
rather than independently.
Also, remove various height corrections and cairo translations that are not necessary or relevant anymore. A subsequent
commit for the GUI will pick up on this work to get the appearance completely correct
Rebasing the feature branch against master was too messy, and only these two files were
changed. The development history of this branch could easily have been --squash'ed anyway,
so not much of a loss
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.
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.
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
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.
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.
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.
