Hey folks,
a DialogWindow opened from a plugin does not scale correctly when moved between screens with different scale factors. Visibly the window resizes but when checking it’s size in the resized() method, it’s logical size changes, which shouldn’t.
That leads to the content being cut when moving a window opened for example on a screen at 150% to screen with 100%.
Doing the same from a standalone app or standalone plugin seems to work.
Checked on Windows 11 and VST3 (Reaper and Cubase 13).
Ok, so here some news about this.
When commenting out the following two lines
if (! isPerMonitorDPIAwareWindow (hwnd))
return 0;
in juce_Windowing_windows.cpp, things start to behave correctly for that. I am not sure, what that will break in other parts but my tests have been promising so far.
This bug is related to:
@reuk This one is also on latest juce tip and again Windows only. Any idea?
There’s a long-standing issue where scale factors on Windows are reported differently depending on whether the project is running as a plugin/library or a standalone app. Although this is something I’d like to address, it’s likely to be disruptive to existing projects, and our focus is on other issues at the moment.
Opening additional windows in a plugin is generally not a good idea. Apple even explicitly recommends against opening new floating windows in plugins in their official documentation.
I understand that some designs require additional top-level windows; however, I’d recommend looking for alternatives wherever possible.
@reuk Yeah, as you said, some designs require it. And although Apple argues against it, which i find hilarious, it works well on Mac. Windows is the bad boy here.
If there would be a way to bypass the above mentioned two lines, preferrably at runtime, things would be much better. After commenting this out, the Windows windows suddenly started working but i do not like to have to comment them out manually every time i update juce. If that could be built in, it would be a minimal change which does not break anything by default.
They recommennd against it specifically because it doesn’t work well on mac, although the problems are only present in AU plugins that are hosted out-of-process. If you’re planning to target AU or AUv3, I recomennd thoroughly testing these formats on both Intel and Arm to make sure that everything works as expected.
@reuk Ah, ok, good to know, thanks. Until now AU works, although with some minor quirks. AUv3 is currently not on the menu.
About the windows issue, would it be possible to put something in there so that these two lines (currently line number 35xy something) can be “commented out” by setting some boolean at runtime, preferrably? That would solve a lot of things in that regard.
Thanks for your patience. We’ve now pushed some changes intended to address this issue. Please find further details here:
Thanks! Much appreciated.
But the new changes introduced a new bug. Everything is working well until opening a Dialog Window and attaching an OpenGLContext to it on Windows.
If the window is opened on the same screen where the main app lives, everything is ok. But if you move the DialogWindow to another screen with another scale factor, everything gets garbled. The very same DialogWindow with exactly the same content but without the attached OpenGLContext shows no such behaviour.
More specifically, the OpenGL content gets partially shown with the scale factor from the screen where the main app is placed, while another part of the content is shown with the scale factor of the screen the DialogWindow has been moved onto.
