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.
This assertion was intended to emulate a performance warning that could
be emitted by the D2D debug layer, but it often gets in the way during
development. To check for this performance issue, users can change
D2D1_DEBUG_LEVEL_NONE to D2D1_DEBUG_LEVEL_INFORMATION in
juce_DirectX_windows.h
Calling getInstance may recreate the list singleton if it has already
been destroyed. This should only happen if a Typeface instance is being
destroyed after the app/plugin has been shutdown, e.g. if the typeface
has static storage duration.
This issue could be seen when calling setBufferedToImage on a component
with a transparent background with a size different to the component's
size.
The details are unclear to me, but it seems like both calling Clear on
the device context, and using the COPY blend mode, ignore alpha values
and instead use a constant alpha of 1.0 when there is a geometric
clipping layer active.
As a workaround for this issue, when clearing a rectangle we now pop all
active layers, fill their intersection using the COPY blend mode while
there are no layers active, and then reinstate the layers.
The new implementation is likely to be very slow, however I think this
code path is unlikely to be used frequently in practice. The main
use-case for rendering clear transparent areas is the rendering of
buffered component images, but such cases normally use axis-aligned
clipping regions, which should be able to use the faster path.
Frequently, excludeClipRectangle will be called several times in a row,
in order to trim away borders on each side of a rectangle. When this
happens, we want to avoid creating geometric clip layers which exclude
only two or three of the borders, and instead wait until all borders
have been excluded before applying the clip list. This way, it may be
possible to simplify the clip list to a single rectangle, which can be
implemented using the faster axis-aligned clipping layer.
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.
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.
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.
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.
Previously, code such as the following would return a smaller string
width for larger tracking values:
juce::Font f { juce::FontOptions{}.withPointHeight (16.0f) };
const auto g = f.withExtraKerningFactor (1.0f);
const auto a = f.getStringWidth ("foobar");
const auto b = g.getStringWidth ("foobar");
With this change applied, the width 'b' is greater than the width 'a',
as expected.
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.
This fixes an issue with the text wrapping logic for text chunks ending
in a whitespace.
When trying to fit a text chunk, the logic works with two values: width
with trailing whitespace, and width without trailing whitespace.
When the trailingWhitespacesShouldFit option is false, the logic
checks if "withoutTrailingWhitespace" can still fit inside the remaining
width.
Prior to this fix, it then decremented the remaining width with
"withoutTrailingWhitespace", but it should have used
"withTrailingWhitespace" for the decrement operation, always, regardless
of the value of the withTrailingWhitespacesShouldFit option.
This mistake only caused an observable issue when multiple fonts were
used for the shaping operation, and a different font would be used
immediately after a whitespace falling at the end of a line.
Prior to this change, the spacing between line N and line N + 1 would be
lineHeight (N).
This resulted in incorrect spacing when using multiple fonts in a text.
This commit uses the correct spacing, which is
maxDescent (N) + maxAscent (N + 1). This is also the same rule that was
used by TextLayout prior to JUCE 8, and the rule that CoreText's
AttributedString features are using as a general rule.
Note: lineHeight (N) = maxAscent (N) + maxDescent (N).
