JUCE 7 OpenGL renderer fails on older MacOS

Thank you for this fix. :+1:

The tester reports back the problem is solved for JUCE 7 with the flushBuffer fix.
Older version of our plugins with JUCE 6 are working together with plugins with this fix, too.
But the tester also confirms that a plugin with JUCE 7 without the fix together with a plugin with this JUCE 7 fix still provokes the freeze.

Good to know, glad this solves the problem! Thanks for the detailed feedback!

I have followed this discussion, but I cannot determine if my plugins are affected, with how I use OpenGL.

I attach an OpenGL context to my pluginsā€™ main editor like this:

    #if JUCE_INTEL
        openGlContext.setOpenGLVersionRequired (juce::OpenGLContext::openGL4_1);
        openGlContext.attachTo (*this);
    #endif

Is this safe, or do the mentioned issues apply here as well?

Thanks in advance,

Peter

Youā€™re affected if:

  • You target macOS 10.13 or earlier
  • You use any OpenGL version
  • You build with JUCE 7 before this commit, or any JUCE version with JUCE_COREGRAPHICS_DRAW_ASYNC enabled.
1 Like

Thank you!

Hi reuk, thank you very much for your quick responses and fixes!

For us, this now means weā€™re stuck at JUCE 6 for the time being - as our share with macOS 10.13 is still quite high (about 1.5% of our macOS users) and I guess that for the next 1-2 years itā€™s just too likely that someone has a JUCE 7 plugin installed that does not have your fix from a few days ago.

Is there any chance that the safe JUCE 6 behaviour could be ported to JUCE 7?

I just tried running two OpenGL-using plugins on 10.12: one built with 6.1.6, and one built with the current develop branch. I donā€™t see any deadlocks in this case, so I donā€™t think thereā€™s any need to ā€˜portā€™ the old behaviour onto develop.

Thank you a lot for testing! What I meant is: Did I understand you right that we can run into deadlocks if a user opens a plugin from some vendor that was built with JUCE 7 before your fix, and then also opens a plugin from us that weā€™ve built with JUCE 7 with your fix?

If thatā€™s the case, then weā€™re stuck to JUCE 6 for long time. Unless thereā€™s be a way to port the old JUCE 6 behaviour to JUCE 7.

I think I see - youā€™d need to set the windowRequiresSynchronousCoreGraphicsRendering flag when creating the peer that backs the plugin editor. Unfortunately, thatā€™s hard-coded in the wrappers at the moment, but we could look at adding some way of making that configurable.

Thanks for your patience. Weā€™ve merged a workaround here:

By default, if the plugin links the juce_opengl module, and is running on an older macOS version, the editor will no longer be layer-backed.

5 Likes

Thank you for the workaround.

Now the tester with an older macOS version reports that a plugin with the old version of JUCE 7 without the flushBuffer fix work together with a plugin with JUCE 7 with the flushBuffer fix and this workaround.

Another tester reports success using the latest macOS version, too.

So the problem is solved for older macOS versions without disturbing newer macOS versions.

Thank you so much :+1: :grinning:

2 Likes