I’m having trouble with the usage of OpenGL under DPI scaling on Windows: I’m attaching an OpenGLContext to my plugin editor, which has both standard JUCE components and GL rendering elements. As soon as I enable DPI scaling:
In Bitwig, the OpenGLContext is for some reason scaled beyond the plugin, like if the scaling was applied twice. So all I’m seeing of the UI is the bottom left corner. From mouse hover actions I can see that the components are actually in the right place as far as interaction goes - they’re just painted beyond the window.
Everything works fine when display scaling is at 100% or if I don’t attach the OpenGLContext.
What could be wrong here? Any help appreciated!
I’ve managed to reduce the problem to a very simple example plugin:
All this does is attaching an
OpenGLContext and adding a
These are the results in Bitwig:
100% scaling (800x600 px)
150% scaling (1200x900 px)
Notice how in the second image, the window is already scaled to 150%, but then the content being drawn is even bigger.
Ok I did some more testing. Bitwig has an option to disable plugin scaling entirely. Funnily enough, after disabling it, plugins will still be scaled but this time without painting beyond the window. Just that it employs a very ugly nearest neighbour interpolation upon rescaling.
I also checked with Vital, which I know uses OpenGL and it has the very same issues.
So at this point I’m pretty certain the issue isn’t in my code, plus there’s a workaround-ish, so the situation is acceptable.
Hi TheWaveWarden, on Windows, in particular in combination with various multi monitor and high dpi settings and OpenGL, there has been a variety of bugs for years now. Partly they are related to JUCE, but I (and some others in the forum) once figured out that there was also a bug in the nvidia GPU drivers that led to incorrect handling of high dpi with regards to the opengl context.
I do not consider “disable high dpi support” or any combination of the “workaround” checkboxes in Reaper a viable solution.
If you search the forum you will find some more extensive threads that attempt to get to the bottom of this. It’s very intertwined and not one single bug, your VST hosts and the VST standard (2 or 3) also play a role here. It plays a small role that over the years and before Windows had a mature High DPI API (which it has now), there have been various workarounds and approaches to tackle the problem, and some of those conflict with each other. For instance, VST3 offers an API to explicitly communicate a scale factor to the plugin. In JUCE itself, you can have: global scale factor, the HWND dpi scale, the thread dpi scale (mind that opengl and the message manager run on different threads), the physical scale factor from your low level graphics context, any sort of affine transform somewhere in your UI hierarchy. Just writing this to emphasize that this is a bottomless pit of complexity under the hood.
I can confirm repros with “template plugin” projects, and I would once more strongly encourage the JUCE devs to look into everything high DPI and multi-monitor related on Windows, with and without OpenGL.
If someone finds a reliable fix, I’m still waiting for one.