If we do that, our plugin is displayed incorrectly, with the graphics scaled up (probably by my monitor scale-factor of 150%) from the bottom-left corner upwards. Mouse interaction is visibly offset by a large amount.
If we don’t attach the OpenGLContext, everything renders correctly.
This does NOT happen in stand-alone mode, only when loaded as a VST2 or VST3 in Cubase 10 (Windows 64-bit). Haven’t tested other plugin formats.
When changing my desktop scale to 100%, everything works correctly.
Can confirm this happens, also in FL Studio 20.5.1.
With some quick debugging, as fast as I could before deadlocking my entire system with GL + FL + my plugin in a bridged mode, getWindowScaleFactor reports the wrong scale in updateViewportSize.
Has this begun recently? I pushed a commit setting the DPI-awareness of the OpenGL worker threads a few days ago here which might be the culprit. Are you able to test before and after this commit to see if it’s causing the problem?
I’ve switched to a revision from a week ago (right before you made that change) and first I was disappointed, because it looked identical, but then, after around 1-2 seconds later it redrew itself at the correct scale.
So without that fix from a week ago, it’s first scaled wrong, but after around a second or two, it refreshed (could have something to do with a “repaint” that I call once another background task completes).
I remember that before this, the scale was also always wrong, until I moved the window with the mouse and thus forced a repaint.
Hmm, I can’t reproduce this in Cubase 10 or FL Studio 20. My desktop scale factor is set to 175% and I’ve tried running Cubase with hiDPI enabled and disabled, and FL Studio with global scale set to “system” and other values… It could be a graphics card specific issue which will be hard to track down, but could you also try with the following modifications to the setThreadDPIAwareness() method in juce_gui_basics/native/juce_win32_Windowing.cpp at line 4098 -
Yes, it renders correctly both with and without an OpenGLContext attached. Are you able to reproduce the issue by just adding an OpenGLContext to the vanilla JUCE AudioPluginDemo and calling attachTo()?
I’ve just made the change you described above (copy’n’pasted the entire block) and it makes no difference for our plugin in Cubase 10 (didn’t test with the AudioPluginDemo).
It worked really better before you made the change a week ago for “Cantabile”, a host nobody ever heard of and not used by a single customer of ours we are aware of, while it broke compatibility with Cubase, a major host on the market.
I highly doubt it’s a graphics-card specific issue. The Nvidia cards we use are extremely popular and we have exactly zero graphical issues otherwise.
Again: it worked fine a week ago. It broke with the commit that fixed the issue in “Cantabile”.
It’s not always so cut and dry. It worked better, as in it displayed with the wrong scale for about a second and then redrew itself correctly right after.
In rare cases moving the windows, opening the start menu or alt-tabbing “magically” fixes the rendering. This is very random though. I get a strong feeling that this might even be a windows or a gpu driver issue… regardless of that, I urgently need some sort of work around. Experimenting with window creation and dpi awareness setters now