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 });
}
Previously, if the PathFlatteningIterator returned a line segment with
very large x or y positions, the result of
roundToInt (iter.y1 * 256.0f)
could be incorrect, if the result was too large to fit in an int.
Using int64_t to store intermediate results, converting to int when
updating the edge table itself produces accurate results for a wider
range of inputs.
Previously, the top-level modal dismiss broadcaster would attempt to
dismiss all modals when the native file chooser was brought to the front
or clicked. This would end up calling Component::inputAttemptWhenModal,
which would bring the FileChooser's Component to the front, interrupting
the mouse click.
The fix is to avoid bringing the plugin window to the front when the
FileChooser is in a modal state. As the chooser is a native window, the
system should take care of enforcing the expected modal behaviour.
It's not clear why this issue only affects Cantabile. It seems that in
Cantabile, events from the native FileChooser get sent to the plugin
editor's parent HWND, whereas this doesn't happen in other hosts.
Perhaps Cantabile is hooking/intercepting window messages in some way.