467f20a7a1 introduced a change to start processing WM_NCMOUSELEAVE
messages as mouse-exit events. This behaviour is not quite correct,
because NCMOUSELEAVE may be triggered when moving the cursor from the
nonclient area to the client area, in which case the mouse is still over
the window.
We now check whether the mouse is really over the window inside
doMouseExit(), and continue to track it if necessary.
This is intended to address an assertion that sometimes fired during
shaping text on Android, for example when using the font "Noto Sans
Symbols" and shaping ASCII text including a line break in a multiline
text editor.
The cause of the issue seems to be that the shaper would search for
substitute fonts using the original string content, but would then
replace some characters in the string during shaping. Shaping could then
fail if the font did not contain glyphs for the replaced characters.
We now create a UTF32 string with replaced characters at the beginning
of the shaping process, and use that new string for all queries other
than unicode analysis.
Android 15+ removed the 'legacy' png-based emoji font. Modern Android
versions may include only a COLR-v1-based font, which JUCE cannot
render itself.
As a workaround, on Android, we use a Canvas object to render each emoji
glyph into a bitmap, and then render that bitmap in the same way as a
legacy png-based glyph. This won't look as crisp as rendering COLRv1
glyphs directly, especially at larger sizes, but this is a sufficient
stop-gap for the time being.
I observed a deadlock when scanning AU plugins in-process in the
AudioPluginHost, and then clicking the "cancel" button in the scan
progress alert window.
The cause of the deadlock seems to be that JUCE uses async messages to
create and destroy AU plugins on the main thread. When running a plugin
scanner on a background thread, it was possible to end up in a situation
where the background thread was waiting on the message thread to process
a create/destroy message; and, at the same time, the main thread was
blocked waiting for all scan jobs to complete. This seemed to happen
because scanFinished() was called directly from the Scanner's
timerCallback as soon as the progress window was cancelled, even if
there was still a scan in progress at that point.
To avoid the deadlock, we now wait until the current scan has completely
finished before allowing the timerCallback to call scanFinished(). If no
scan is in progress, then the main thread can safely destroy the scanner
ThreadPool without needing to wait at that point.
In the old implementation, because pushSample() could be called on the
audio thread, and updated the levels array and the nextSample value
non-atomically, other threads (e.g. the UI thread) were not guaranteed
to see these updates in a consistent order.
