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.
The OpenGL renderer listens for imageDataChanged() to invalidated cached
textures.
Before this change, the SimpleFFTDemo would display a static (outdated)
image on Windows when using the OpenGLRenderer.
When syncing from CPU->GPU storage, we currently copy the entire image
contents. The contents of the CPU backup completely replace the old GPU
image. Therefore, if any pixels need to retain their existing values, we
need to read those pixels before overwriting them. This in turn implies
that, when a BitmapData refers to a subsection of the image, we should
always flush GPU->CPU storage first, so that the subsequent CPU->GPU
sync doesn't clobber pixels outside of the BitmapData region with
outdated values.
It's clear that copying the entire image back and forth could be
suboptimal when writing to image subsections, but to optimise this
process we'd have to keep track of dirty image regions or similar, which
may in turn pessimise more common cases.
This makes Direct2DMetrics and current frameId accessible to implementation subclasses.
It also replaces JUCE_WRITE_TRACE_LOG with JUCE_WRITE_TRACE_LOG_VA as intended in original implementation.
Co-authored-by: Matt Gonzalez <matt@echoaudio.com>
This addresses the same issue that
95d416ab77 was intended to fix:
Drawing a drop shadow on a high-res display on Windows could sometimes
produce thin lines around the edge of the shadow. Using the 'clamp'
rather than the 'wrap' clipping mode seems to help.
Previously, plugins and standalone apps could produce slightly different
visual results, particularly anti-aliasing, when displaying on a display
with native scaling applied. The discrepancy was caused by SetDpi being
called with a larger-than-default value (e.g. 192 DPI on a 200% scaled
display) in a standalone app, whereas SetDpi would always be called with
the default value of 96 in a plugin.
Keeping the default value seems to produce better results, so standalone
apps will now retain the default DPI.
