The other renderers implicitly start a new supath at the last path
location when a line or bezier segment is added without explicitly
starting a new subpath.
Problem description
===================
Firstly, the linked-list of pending presentations acted as a stack
(FILO). If the swap chain thread and main thread processed frames at
varying rates, then the following sequence of events was possible:
Main thread Swap chain thread Queue state
---------------------------------------------------------
Push frame (1) [1]
Push frame (2) [2, 1]
Pop frame (2) [1]
Push frame (3) [3, 1]
Pop frame (3) [1]
Pop frame (1) [] <-- Out of sequence!
Secondly, the swap chain's sequential flip model can only maintain a
valid back-buffer state as long as the list of dirty rects is correct,
and every pixel within the dirty rects is painted incrementally.
In the example above, if the main thread were to produce two frames
before the swap chain thread could present any frame, then presenting
*only* the frame 2 (skipping frame 1) may produce incorrect results when
combined with the existing back buffer. This is because regions updated
in frame 1 may not be updated in frame 2, so regions *only* updated in
frame 1 will be omitted from the back buffer.
Mitigation
==========
This patch removes the old stack of presentations and replaces it with a
slightly more complex mechanism that tracks two different Presentation
objects. At any time, up to one Presentation may be in use by the swap
chain thread (i.e. actively presenting), up to one Presentation may be
accumulating updated/dirty regions (i.e. painting), and up to one region
may be ready, awaiting display.
This scheme resolves the first issue described above by ensuring that
old frame data is not kept around. There is never more than one frame
awaiting display, which means that if the swap chain thread attempts to
display twice in a row (before the main thread produces a new frame),
the second attempt will be a no-op.
The second issue is resolved by accumulating changes into a single
Presentation whenever the main thread produces two or more frames in a
row. If there is already a 'ready' Presentation when the main thread
finishes painting, then all updated regions from the newest Presentation
will be added to the 'ready' Presentation, rather than replacing it.
When the swap chain thread is ready to present, it will therefore see
the result of all the accumulated Presentations produced by the main
thread, instead of just the newest Presentation.
The ScopedJuceInitialiser may have been destroyed before shutdown is
called, in which case singletons will have been deleted and cleared.
Attempting to access the ModalComponentManager here will recreate it,
and will trigger a leak detector warning later on.
Since 4122427748 assertions are guarding
the FontOptions::withName, withStyle and withTypeface member functions.
Since then the only way to replace an existing typeface without hitting
these assertions is to clear all three fields before calling
withTypeface, which then sets all three values. It is always legal to
just clear an existing Typeface and rely on the name and style fields.
Previously, MIDI FX would report an input and output channel count of 0.
However, a non-empty output bus is required in order to retrieve the
processing sample rate.
With this change in place, MIDI FX plugins will now report an output
channel count of -1, which indicates that any number of output channels
is valid.
Before this change, after running a JUCE app on Windows under a
debugger, and quitting it normally (e.g. pressing the close title
button), the output log would display some memory leak diagnostics. This
is because HarfBuzz expects to clean up statics using atexit, but atexit
was not enabled. This change enables atexit on supported platforms,
including Windows.
Reading or writing the kAudioUnitProperty_AudioChannelLayout property
could result in out-of-bounds reads or writes as AudioChannelLayout
has a variable length array as the last member of the struct
