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.
This assertion is intended to mirror the behaviour of an
informational/performance diagnostic message raised by the D2D debugging
layer.
It seems the D2D diagnostic is raised when the proposed clip region is
aligned to the screen, not to the current transform.
Before this change, the assertion could incorrectly fire when clipping
to transformed rectangles. This could be seen when clicking the
star-shaped buttons in the ComponentTransformsDemo.
With this change in place, the assertion will still fire when e.g.
calling Graphics::reduceClipRegion on a screen-aligned rectangular path,
but will not fire when this path is skewed/rotated etc.
Resizing using window manager functionality (e.g. clicking and dragging
in the non-client area) will send WM_SIZING to the window, which in turn
will enable continuous repainting in the D2D renderer until the resize
operation ends.
Continuous repainting is required in order for the window to display
correctly during the resize. Without continuous repainting, some frames
may not be completely painted, and may display with black areas,
producing a flickery effect.
When a resize is controlled entirely by the client, e.g. using the
corner resizer in the AudioPluginDemo standalone, WM_SIZING is never
posted. Instead, we assume that if the window has captured the cursor
during a setBounds call then it is probably resizing. We enable
continuous repainting in this case, and stop repainting once the window
releases the mouse.
An alternative appropach would be to add some kind of start/stop resize
API to ComponentPeer. I'm currently reluctant to do that because the
ComponentPeer API is already so large.
Previously, drawing an opaque, scaled component with CoreGraphics could
lead to visible artefacts around the edge of the component.
When drawing the parent of an opaque component, the area covered by the
opaque component is excluded from the clip region. If the clip region is
non-integral when transformed into device space, anti-aliasing will be
applied on the edges of the clip region. Similarly, when drawing the
opaque component itself, anti-aliasing will be applied at the edges of
the component. When the two drawings are superimposed, the foreground
anti-aliased pixels will be blended with the background anti-aliased
pixels, leading to a noticeable border around the component. Ideally,
only the foreground anti-aliasing should be applied, and the background
should not be anti-aliased around its edges.
Previously, the software renderer could render transformed gradients
incorrectly. This could be seen in the backgrounds of the tabs in the
ComponentTransformsDemo when the view was rotated through around 45
degrees.
The new behaviour appears more consistent with the other renderers.
The glyph spacing for this font does not scale linearly with the font
size; at smaller font sizes, the spacing is relatively larger.
Typeface::getStringWidth, Typeface::getGlyphPositions, and the
equivalent Font member functions now take the font size and horizontal
scale into account when computing advances on Apple platforms.
This is sufficient for initial support of the system emoji fonts on each
platform:
- Noto Color Emoji on Linux and Android, png-based
- Apple Color Emoji on macOS and iOS, png-based
- Segoe UI Emoji on Windows 10 and 11, COLRv0-based
- This font also provides COLRv1 support, at least on Windows 11,
but JUCE will ignore that and use the COLRv0 data instead
