Previously, code such as the following (where MyGLComponent is rendering
using an OpenGLContext) could result in GL errors, as the destruction of
the inner context unbound the array buffer and element array buffer
after use, instead of setting them to the previous values set up by the
outer context.
Additionally, a VAO was only set up in the OpenGLContext, so rendering
into a GL-backed LowLevel graphics context could fail if no VAO was
bound.
void MyGLComponent::paint (juce::Graphics& g)
{
juce::Image image { juce::Image::PixelFormat::ARGB, width, height, false, juce::OpenGLImageType() };
{
juce::Graphics innerContext { image };
// draw into innerContext
}
g.drawImage (image, juce::Rectangle<float> { width, height });
}
The OpenGL renderer uses ColourGradient::createLookupTable to generate
gradient textures. However, the tweening method used was different to
the tweening used by CoreGraphics gradients, and by the software
renderer.
Gradient tweening is now computed using non-premultiplied colours, to
ensure consistency between gradients rendered using OpenGL, and with
other renderers.
This change fixes an issue where opening multiple OpenGLContexts on
certain versions of macOS (observed on 10.13) could cause a deadlock.
The issue can be reproduced by:
- Attaching an OpenGL context to the AudioPluginDemo editor
- Opening multiple copies of the editor simultaneously in a plugin host.
I tested with Live 10.
I also observed the issue in a standalone app that opened new windows
containing OpenGLContexts on a timer.
On Windows, the OpenGL context window sometimes receives a repaint
request after moving between screens with different scale factors.
If the screen has changed size/scale since the last paint operation,
failing to invalidate the painted area may cause the screen contents
to be drawn at the wrong scale until paint is next called.
- 4.1 and 4.3 contexts can now be requested
- The requested context version is no longer ignored on Linux
- Debugging contexts are now enabled in Debug builds with GL 4.3
- Fixes a bug where glEnable(GL_TEXTURE_2D) was called in core profiles
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".
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 */ });
Previously, we were always adding a #version 150 directive to shaders
when the GLSL version was higher than 1.2, which could cause compilation
to fail on platforms with GLSL versions between 1.2 and 1.5.
Anthony Nicholls
Tom Poole
reuk
attila
ed