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.
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.
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.