This currently happens with the Windows setting “Change the size of text, apps, and other items” set to 125% (scaling factor, I believe). When this is turned back to 100%, the application renders properly.
When this change is applied to Juce, as well as disabling the JUCE_WIN_PER_MONITOR_DPI_AWARE option in the juce_gui_basics module, applications are again scaled and displayed properly, except that the window will not fill the entire screen area when maximized:
Why are you disabling the JUCE_WIN_PER_MONITOR_DPI_AWARE flag? It needs to be enabled for the application to scale correctly when the system scale factor is changed.
That’s what I believed to be the case, but either with stock Juce, or with the modification mentioned by you back in December, building anything graphical shows the “fuzzy” non-scaled interface as shown in the first screenshot, if windows scaling is set to anything above 100%.
Disabling JUCE_WIN_PER_MONITOR_DPI_AWARE is the only way to display a properly-scaled interface at Windows scaling above 100%, though as you mention, if scaling is then changed to 100% while the Juce application is running, it then shows smaller-than-normal (again, expected). But it’s evident that there’s some sort of scaling issue in the default build of Juce. I’d love to test any potential fixes or help nail down what might be causing it.
OK, so after re-reading your initial post I’m quite confused. The change that you linked to which you say fixes scaling issues is in the Windows OpenGL renderer code, but the screenshots that you’ve posted are of the Projucer which uses the software renderer so it would have no effect. Your screenshots also show the Projucer with a non-native title bar so are you using a modified version?
Regardless, I can’t reproduce either of your issues on Windows 10.0.17134 - JUCE apps are rendered correctly without blurring on a scaled display with the JUCE_WIN_PER_MONITOR_DPI_AWARE flag set and even when I disabled this flag, I can’t reproduce your maximising issue. Are you using the latest version of JUCE? Try pulling the develop branch and re-building your project.
I did as requested and downloaded the latest develop off of GitHub, and compiled both stock and only with the JUCE_WIN_PER_MONITOR_DPI_AWARE flag turned off. This is what I continue to get with Juce being compiled directly from GitHub with absolutely no changes:
So still having issues with scaling not happening properly. The next screenshot shows the exact same build with the only change being the JUCE_WIN_PER_MONITOR_DPI_AWARE flag being turned off:
So evidently that flag is having some effect on applications. I’m not sure which ‘renderer’ is used by default on Juce (never had to dive that deep into it), but whatever it is, it seems to be taking that flag into effect at some point.
Also to note, since you did mention it, the previous shots of the Projucer that I posted with non-native titlebars were of my locally modified copy of Projucer. Those were the only changes made to it (setUsingNativeTitleBar(false)). Also to note when building the develop without that change, in the second instance with JUCE_WIN_PER_MONITOR_DPI_AWARE set to off and having the native window manager handle the window, it properly goes into fullscreen, whereas using the Juce titlebar/window management, it does not (does the 3/4-ish maximization shown in earlier post).
OK, the fullscreen issue should be fixed on develop with commit aaaa9e6, but I’m still interested as to why your app looks blurry when JUCE_WIN_PER_MONITOR_DPI_AWARE is enabled - I’ve tested two machines running Windows 10 and they both render correctly and crisply with the flag enabled. It shouldn’t even make a difference as this flag enables per-monitor DPI awareness which would only affect the app running on an external monitor with a different scale factor to the primary display. It could be the version of Windows that you’re running, which version of Windows 10 are you using?
It’d also be useful if you could put some breakpoints in the setDPIAwareness() method of juce_gui_basics/native/juce_win32_Windowing.cpp so I can see what DPI awareness version the app is using. Can you put breakpoints at line 383, 389, 396, 404 and 411 of that file and see which one is hit when you run your app?
Looks like it breaks at 389 (setProcessDPIAwarenessContext != nullptr && SUCCEEDED)
Edit:
To follow up, the Windows build I have been using for all of this has been 1607. I grabbed the latest windows 10 ISO and ran it on VirtualBox on the same machine, set scaling to 125% as before, and used the latest develop from github, this time avoiding any of the blurry scaling issues:
So it would appear that this isn’t the fault of Juce, but rather of something in the way the old Windows builds handle scaling.
If you’re still curious though, I ran the same breakpoints as before in the correctly-displaying build, and it broke at the same point.
To follow up (not that it will help a ton), but curiosity got the best of me, and thinking that maybe, somehow, Juce was using an OpenGL renderer without me knowing, I ran the Hello World test program and used ComponentPeer::getAvailableRenderingEngines() to see if OpenGL was even shown as being available.
“Software Renderer” was the only returned value. So I’d fairly comfortably say that it isn’t OpenGL somehow affecting it. I would also imagine that the previously-mentioned JUCE_WIN_PER_MONITOR_DPI_AWARE option somehow has an affect outside of the OpenGL renderer, but how it’s related to this issue, I could not say.
Last thing that comes to mind is that the ‘GPU’ inside of the virtual machine may somehow have an effect on rendering the program that the actual hardware GPU does differently? The hardware I’m running on is an Intel graphics card.
Also of interest, something I haven’t noticed before, but I downloaded the old 5.2.0 release, and built the demo application. Oddly enough, it seems to display properly with absolutely no modifications at all, simply downloading, opening, building, and running.
No, I think you’ve misunderstood what I was saying. You linked to this commit in your original post which would only have an effect on the OpenGL renderer. The JUCE_WIN_PER_MONITOR_DPI_AWARE flag changes the behaviour of both the software and the OpenGL renderer.
I can also confirm this is true, set JUCE_WIN_PER_MONITOR_DPI_AWARE to 0 actually make it hires. Tested on windows 10 virtual machine via vmware fusion/
If you look at the code, you can see that setting that flag to 0 just means that we set the application’s DPI awareness to system aware instead of per-monitor aware -
Have you updated your version of Windows 10 like the OP suggests?
