Previously, when attempting to create a font with a name different to
that of any font on the system, the returned typeface could be nullptr.
This could lead to crashes when attempting to use the typeface.
Now, if we fail to find a matching font using DirectWrite, we fall back
to the older LOGFONT and DC approach, which will generally locate a
usable typeface, though not necessarily an exact match.
The new behaviour more closely matches the behaviour of JUCE 7, which
would attempt to construct a DirectWrite typeface, but would fall back
to creating an HFONT on failure.
The main reason for removing this call is that this function is
deprecated, and is no longer needed now that we keep our own cache of
CTFonts that have been loaded from memory, and now that we no longer use
CoreText text layouts.
This also appears to fix an issue with garbled text which was
occasionally seen when different versions of the same font were
available, e.g. because differing versions of the font were
simultaneously embedded as BinaryData and installed on the system.
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.
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.
