ARDOUR_UI::load_session() calls flush_pending() which runs
gtk_main_iteration()s until idle.
If a user selects another snapshot from the sidebar, load_session()
is called again (from a call to load session)
The midi_input_handler for the AsyncMIDIPort is connected to the
main event-loop. Events may still be delivered after the surface was
destroyed.
That by itself is not harmful, unless a given message produces a reply:
The _output_port is already gone, FaderPort8::tx_midi crashes.
When triggering Session::undo() or Session::redo() from a
non-GUI-thread (e.g. from a surface protocol) Ardour crashes if setting a
CairoWidget dirty due to a ENSURE_GUI_THREAD assertion. (see #7371)
By triggering undo by BasicUI::access_action() rather than by Session::undo()
we ensure that the GUI thread will finally call Session::undo().
So more like a workaround ... but better than crashing :)
If pending_visual_change.pending was zero when calling idle_visual_changer
the handler_id was never reset. and the idle-handler was never called
again.
The vast majority of errors reported by users as
"Cannot configure audio/midi engine with session parameters"
have nothing to do with engine-parameters.
Fix potential crashes in case fluid-synth runs into an OOM error,
and address a const-cast compiler warning.
Switch to track github repo (instead of sf.net git)
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
