This updates the behaviour of Typeface::getStringWidth,
Typeface::getGlyphPositions, and Typeface::getEdgeTableForGlyph to match
the documented behaviour of these functions. Previously, these functions
returned results normalised to a size of 1 point. The new (documented)
behaviour is to normalise to a JUCE height of 1.0 - that is, scaled so
that the sum of the ascent and descent is equal to 1.0.
CGContextGetClipBoundingBox sometimes returns a 'null' rect. When it
does, the following logic will get stuck in the while loop drawing
individual tiles over and over again.
Alternatively we could disable antialiasing before the fill operation
but this could cause neighbouring Components to overlap on the screen
even if their coordinates don't.
In CoreGraphicsPixelData::createImage, image data was copied from a
BitmapData created from the Image passed into the function.
The BitmapData instance didn't keep track of the size of the buffer it
pointed to, so the buffer size was computed by multiplying the
BitmapData height by its line stride. However, if the BitmapData pointed
to a subsection of an image, the `data` pointer might be offset from
the allocated region, and `data + lineStride * height` would point past
the end of the allocated region. Trying to read/copy this range would
cause a heap buffer overflow at the end of the range.
This change adjusts BitmapData so that it keeps track of the size of the
allocated region. Taking a subsection of an image should subtract the
data pointer offset from the size of the allocated region.
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.
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 */ });
