Using OpenGL on Windows with a display scaling factor seems to have issues. I’ve had a similar problem recently. No solution so far, but there’s some more info in this thread:
It might be related to what graphics card you’re using. So far I’ve not been able to find a solution. The only thing putting my mind at rest is that this will happen with every plugin using OpenGL, not just yours. So hopefully, users will disable OS scaling or find the option in their host to disable scaling for plugins (if there is any).
FWIW I fixed a couple of OpenGL scaling issues very recently on develop. If you haven’t tested with the very latest develop branch, it might be worth updating.
OpenGL support on high-resolution displays seems to be a bit hit-and-miss on Windows, and can be dependent on the installed drivers/hardware. I’ve personally seen different behaviour between integrated Intel hardware and discrete Nvidia hardware. If you’re able to test any non-JUCE OpenGL plugins, it would be interesting to know whether those work properly for you.
I’m planning to test this Pro Tools issue soon, hopefully in the next week.
I’ve now tested a modified version of the AudioPluginDemo that calls OpenGLContext::attachTo on the top-level editor component in Pro Tools 2022.5 and 2022.7. I’m testing on Windows 10 21H2, with the display scale set to 150%.
In Pro Tools 2022.5, the entire UI of the application (including the plug-in editor) seems to be automatically stretched by the OS to match the requested scale factor:
I think the problem is that in PT2022.7, the system reports that the native scale factor of the editor window is 1.5, but the physical size of the window is set as though the scale factor is 1. It looks like we might be able to get a more accurate scale value by comparing the logical size of the editor against the physical size of its window, rather than depending on the OS-provided scale.
Please could you try applying the provided patch, and check whether the results are any better?