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.
The Apple threading documentation [^1] says the following:
> The second argument to pthread_setschedparam is the desired policy,
which can currently be one of SCHED_FIFO (first in, first out),
SCHED_RR (round-robin), or SCHED_OTHER. The SCHED_OTHER policy is
generally used for extra policies that are specific to a given
operating system, and should thus be avoided when writing portable
code.
This appears to differ from the policy semantics on Linux and BSD, where
FIFO and RR are both explicitly real-time policies.
Therefore, on Linux/BSD we only enable the RR policy if the requested
priority is 8 or higher. Meanwhile, on macOS, we map all thread
priorities (0 - 10) onto the RR policy with an appropriate priority.
[^1]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html
The Apple threading documentation [^1] says the following:
> The second argument to pthread_setschedparam is the desired policy,
which can currently be one of SCHED_FIFO (first in, first out),
SCHED_RR (round-robin), or SCHED_OTHER. The SCHED_OTHER policy is
generally used for extra policies that are specific to a given
operating system, and should thus be avoided when writing portable
code.
This appears to differ from the policy semantics on Linux and BSD, where
FIFO and RR are both explicitly real-time policies.
Therefore, on Linux/BSD we only enable the RR policy if the requested
priority is 8 or higher. Meanwhile, on macOS, we map all thread
priorities (0 - 10) onto the RR policy with an appropriate priority.
[^1]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html
Previously, we were using the window's top-left position to determine
the scale to use for the OpenGLContext. However, on macOS the
backingScaleFactor of the window is not strictly related to the top-left
corner of the window, so the OpenGL view's scale could end up differing
from the backing scale factor when slowly moving a window between
displays with different backing scale factors.
On macOS, we now use the backing scale factor of the window's screen (as
maintained by AppKit), rather than trying to work out the correct
display and scale ourselves.
This fixes an issue on iOS platforms where the version number string is
prefixed with "OpenGL ES " despite the Khronos docs for OpenGL ES
specifying that "The GL_VERSION and GL_SHADING_LANGUAGE_VERSION strings
begin with a version number".
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 */ });
reuk
Tom Poole
ed
attila