I had a rough plugin launch last week, which boiled down to me naively upgrading to JUCE dev tip the night before release. This was of course after all beta testing had been done. I tested the code on my beefy machine and it worked out on Windows and MacOS.
It turned out later, that things did not work out on systems, which from my best knowledge are lower end Windows machines without a dedicated GPU. The issues would also be present in some hosts (Ableton, Cantabile) and not others. My best guess is that this is in light of the recent threading changes made to the OpenGL code in JUCE:
The issue manifested itself in an extremely sluggish UI which made the entire host unusable in terms of mouse interactions. The plugin does nothing fancy: It has a big MSEG section which is drawn “natively” with OpenGL, the rest is standard JUCE knobs 'n pieces. The editor is, however the OpenGLRenderer, so native JUCE calls are also forwarded to OpenGL.
My journey with JUCE7 goes as follows:
I initially started out with 7.0.0. But I hit a roadblock, when the editor would crash on close. See this thread:
After which I updated to 7.0.1. Then I read this thread, which states that 7.0.1 won’t work on older MacOS versions.
I cannot test this, since I don’t have an such a MacOS version. This made me upgrade to dev-tip last minute.
Now my conclusion is that from 7.0.0 to dev tip (last Wednesday) there isn’t a version of JUCE suitable for OpenGL on Windows and MacOS? I don’t want to rule out the possibility that there is an issue on my side still.
I want to make it clear that I don’t mean to point fingers here or blame anyone. I’ve upgraded last minute in the knowledge that things could go wrong, which is a silly thing to do. I just want to spawn a discussion and know if I really need to downgrade to JUCE 6 in order to make OpenGL work. I rolled back to 7.0.1, which, as described above will probably not work on older MacOS.
I’m sorry that updating JUCE caused you problems.
Yes, there are currently some issues with OpenGL rendering. It’s the main thing that I’m focusing on improving at the moment. Unfortunately, because the surface area of the feature is so large (it’s affected by operating system version, installed hardware, choice of plugin host, HiDPI support, and more) it’s really difficult to be sure that everything works as it should after making changes in this area. The last round of changes were intended to improve compatibility with older macOS versions, but this does appear to have introduced new issues on Windows, which I’m currently investigating.
Ok thanks for answering! I can understand that OpenGL is a mighty beast to tame under the conditions you mentioned.
Could you give me a hint as to what version is safe to roll back to? Is the last stable JUCE 6 version gonna do it or were the problematic changes introduced gradually in the later versions of 6?
The problem also stems from a missing minimal example of the issue. The JUCE GL demos mostly work fine in an isolated space (as standalone app), since they only draw lightweight stuff. No images, no texture uploads, no framebuffer switches. But when drawing a 60 fps display, in a DAW that shares plugin instances, with multiple open UIs, the problems have appeared in almost every Windows version since the beginning of time. That there are “driver related” problems is a myth of some rare black screens due to outdated GL implementations of integrated Intel HD graphics. And HiDPI issues only manifest as “wrong scaling”.
If we had a common demo to test, together with a query helper of the used driver/system/extensions and capabilities, it would be easier to say: Here JUCE 6.x. works on “this and that” condition. JUCE 7.0 slows down “that” part on “this OS version” in “this” DAW.
I maintain a custom duplicate juce_opengl module and occasionally merge in changes from dev. I don’t test on older macs. But if someone could build a minimal example of JUCE 6 working on Windows 10, JUCE 7 (recent dev changes) not working (or slowly) on Windows 10, I could test if the custom fixes resolve the issues.
