We are adding plugin hosting to our non-JUCE GUI application by using JUCE as a shared library.
Everything working nicely except that on Windows, plugin UIs don’t respond to desktop scaling.
I tried fixing this by using
ScopedDPIAwarenessDisabler to disable DPI awareness before creating the plugin editor and window.
However, this does not work because
setDPIAwareness() in juce_win32_Windowing.cpp checks
JUCEApplicationBase::isStandaloneApp() before doing its thing.
If I comment out the check, then
ScopedDPIAwarenessDisabler works and I get correctly scaled UIs.
So my question: what is the purpose of the check for standalone? Is it actually needed? Is commenting it out likely to cause any issues?
In general, only the host process should be aware of the DPI awareness settings on Windows and is responsible for communicating this to the other parts of the application. The
isStandaloneApp() check in
setDPIAwareness() is for the case of plug-ins where the scale factor is communicated via the various host callbacks and mechanisms for the format and the plug-in should be DPI “unaware” in that it assumes a backing scale factor of 1.
Your use-case is slightly different in that it sounds like you are running the actual hosting code inside a dll that is loaded by another process. Without knowing more about what you are trying to achieve it’s hard to say, but I think it should be relatively safe to comment out that check in your hosting dll and use the
ScopedDPIAwarenessDisabler since it will just set the DPI awareness of the current thread and will reset it when it goes out of scope.
Thanks for the reply @ed95
Based on what you’ve described, it sounds like
setDPIAwareness() should be performing a check to determine if the caller is a plugin, not if it is standalone. This is because “not standalone” doesn’t logically imply “is plugin” since “not standalone” also includes “is static or dynamic library”.
The DPI awareness therefore breaks in a scenario where JUCE’s UI code is used in a library context.
Commenting out the
isStandaloneApp() check “works” for me, but it’s not ideal as it means we need to fork JUCE.