The drawing itself should be unchanged but much of the rest of the
implementation has changed. The WaveViewThreads and WaveViewDrawingThread
classes were added and allow multiple drawing threads.
The Item::prepare_for_render interface is implemented by WaveView to enable
queuing draw requests for the drawing threads to process as soon as the state
change occurs during Editor::visual_changer, which often means the images will
be finished by the time they are needed in WaveView::render. This can
significantly reduce total render time and also flickering caused by images not
being ready for display.
If the drawing thread/s cannot finish the request by the time it is required in
WaveView::render then cancel it and draw the WaveViewImage in the GUI thread if
it is likely it can be completed in the current render pass/frame. This change
also helps reduce the flickering caused by images not being ready with threaded
rendering, but with several drawing threads, drawing in the GUI thread may not
often occur (unless explicitly requested).
Allow unfinished images to be returned from the cache in
WaveView::prepare_for_render so that new draw requests aren't queued for
duplicate images. This reduces the amount of drawing for instance in
compositions where there are many instances of the same sample/waveform
displayed on the canvas as only a single image should be drawn.
Use a random width within a certain range for
WaveView::optimal_image_width_samples so that image drawing is less likely to
occur at the same time (which will cause a spike in render/draw time and
increase the chance of flickering waveforms).
Move implementations of the private WaveView classes into wave_view_private.h
and wave_view_private.cc source files.
Incorporate a fix for limiting the waveview image size to the cairo image size
limit.
Should hopefully Resolve: #6478
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.
Remove Canvas::Layout, use Canvas::Container for the same purpose, move child-rendering into Item::render_children() so that it
could theoretically be used by any derived type.
The idea now is that a scroll group item can be added to the canvas which will causes its children to scroll in either or both
directions (horizontal or vertical). There are few complications: the position() of the ScrollGroup is ambiguous depending
on whether you want it with scroll taken into account or not, so Item::canvas_position() was added, which defaults to
the same value as Item::position() but is overridden by ScrollGroup to return the position independent of scrolling. This
method is used when translating between item/canvas/window coordinate systems.
Note that the basic idea is that we MOVE the scroll group when a scroll happens. This mirrors what happens in the GnomeCanvas,
where Nick Mainsbridge came up with a great idea that allowed unification of the time bar and track canvases.
