Hi, I’m back with my DPI issue fix for Windows See my previous post which holds a potential fix for Juce 5.3.2. We’ve now upgraded our code base to use Juce 6.0.5 instead, and so I needed to re-apply a similar fix again.
The issue is that (on Windows) standalone Juce applications have proper DPI scaling, and I imagine VST plugins have proper support too (I read something about the host passing on the scaling to use to the plugins?), but plugins for unrelated applications are left at the mercy of their host application’s DPI handling setting. In case we’re not a standalone app, Juce defaults to a 100% DPI scaling, so when the host informs Windows it’s perfectly DPI aware, this results in tiny controls on high DPI monitors in standalone Juce dialogs.
The fix I applied is that when we’re not a standalone app, I query for the DPI support the host has set once, and then (where needed) toggle the DPI support to “per-monitor aware” using SetThreadDPIAwarenessContext for the current thread (and revert it back when not needed anymore). This way no matter which DPI support the host has, the Juce dialogs get sized correctly and look nice and crispy.
Where this is not supported (pre-Windows 10.1703), the code could fall back to use SetThreadDPIAwareness instead (for everything from Windows 8.1 upward); this has to be added to the code though.
There are probably quite a few issues with the code though… For one, I added all of this behind the preprocessor define JUCE_WIN_PER_MONITOR_DPI_AWARE, so for code bases not using this define the fix won’t work (don’t know if that would even make sense though). But I tested it on Windows 7, Windows 8.1 and Windows 10 for one particular host (Adobe Premiere), and on all those combinations the result is good. Then again the changes might very well wreck havoc for VST plugins under their hosts; there’s no way for me to test for that.