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.
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.
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
Previously, it wasn't safe to access Font instances from multiple
threads because there was a chance that they might reference the same
shared internal state. In this case, calling getTypeface() or getAscent from
two threads simultaneously would cause a race on the typeface and ascent
data members, even though the Font instances appeared to be disjoint.
With this change in place, it is now safe to use Font instances from
multiple threads simultaneously.
It is still an error to modify the same Font instance from multiple
threads without synchronization!
// Fine:
Font a;
Font b = a;
auto futureA = std::async (std::launch::async, [&a] { /* do something with a */ });
auto futureB = std::async (std::launch::async, [&b] { /* do something with b */ });
// Bad idea:
Font f;
auto futureA = std::async (std::launch::async, [&f] { /* do something with f */ });
auto futureB = std::async (std::launch::async, [&f] { /* do something with f */ });
