Previously, lifetime management of CTFontRefs was not implemented
correctly. For zero-length ranges, the font may not be retained when
applying it to a CFAttributedString, meaning that the reference stored
in the fontMap sometimes became invalid before
createCFAttributedString() returned.
We now retain font refs when adding them to the font map, and release
them when the map is destroyed, ensuring that the font references remain
valid throughout the lifetime of the map.
With this patch applied, the DemoRunner should build under MinGW, and be
(nearly) feature-complete compared to the MSVC build.
Specifically, when building with MinGW:
- Adds support for accessibility
- Fixes build issues in the juce_video module
- Fixes a link issue in the VST3 wrapper when VST3_CAN_REPLACE_VST2 is
defined
- Adds support for the new-style native FileChooser
- Tidies up some other low-severity warnings
Known issues:
- Direct2D rendering is still not supported when building with MinGW due
to ABI compatibilities.
This commit removes the various compiler-specific JUCE_DEPRECATED macros and replaces them with C++14's deprecated attribute. It also removes the JUCE_CATCH_DEPRECATED_CODE_MISUSE flag as we can rely on the override specifier catching usage of these old virtual methods, and tidies up the DOXYGEN preprocessor checks as they were inconsistent across the codebase.
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 */ });
In particularly unfortunate cases, the fonts used for laying out and
drawing an AttributedString could end up differing, meaning that
incorrect glyph indices would be used during rendering. The rendered
text would end up using incorrect character symbols, making it
unreadable.
The problem seems to be:
- The AttributedString fetched a typeface during the getOrCreateFont
call in createCFAttributedString.
- Details of the typeface (its style and name) were stored into the
CFAttributedString.
- During `createLayout`, a new `Font` object was created using the
stored typeface name and style.
- When calling `getTypeface` on this new font, during rendering,
a different typeface was returned.
The fix implemented here stores the Font objects used during the
creating of the CFAttributedString, so that the fonts written to
the juce::AttributedString are guaranteed to match the fonts used
to compute the layout.
Previously, the following plugins were causing issues when hosting their
editors:
- Softube plugins. I used Saturation Knob for testing, which crashed when
deleting the temporary parent view.
- KORG Gadget series, which displayed a black screen after the temporary parent
view was deleted.
- FabFilter Pro-C, which displayed at the wrong scale when opened on a
retina display.