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.