Fixes bugs in AndroidInputStreamWrapper introduced in
0d2e34f34c
- Now that AndroidInputStreamWrapper is moveable, its destructor must be
able to handle the situation where stream is null
- The move assignment operators of AndroidInputStreamWrapper and
AndroidContentUriInputStream could previously end up calling
themselves recursively
Reverts b12088a1f6
After some investigation, it appears that ClearType rendering is
unsuitable when
- the render target has translucent pixels underneath rendered text, or
- the render ouput is rotated, scaled, subpixel-translated, or otherwise
transformed before display.
This necessitates avoiding ClearType when rendering into transparent
bitmaps.
Unfortunately, a commmon use-case for transparent bitmaps is buffered
component images. Even if ClearType were enabled for opaque targets,
ClearType text could then end up displaying next to non-ClearType text
rendered to an intermediate texture, leading to an inconsistent
appearance.
There's also not a straightforward way of exposing a ClearType rendering
option in all of the places that it would be required, and a change of
this size is difficult to justify given that subpixel text rendering
controls would only have an effect on Windows.
Previously, this function didn't store/copy the provided bitmap, so the
resulting image was blank. This also broke createSnapshot(), which would
always return a blank image.
This change also moves the startFrame and endFrame calls out of the
plain Direct2DImageContext and into a special-purpose "flushing" context
that is private to Direct2DPixelData.
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.
