Desktop::getInstance().getDisplays().getMainDisplay().scale does not return the correct value after upgrading to JUCE6 (from juce 5.4.7)
On Windows always returns 1 (not tested on osx)
Tested on latest windows 10, on a 13 inch laptop with 150% desktop scale. On juce5 it returns the correct value: 1.5
EDIT: I tried with getApproximateScaleFactorForComponent() but it doesn’t always work, for example if you call it from constructor. I usually choose images to be loaded at constructor.
Is this as a plugin or standalone app?
I hit this issue where plugins on Windows always report 1. I assumed it was always like this. I had to fork JUCE to work around it.
I think the change was made to make things work the same on Mac and Windows and also to work the same way in plugins and standalone apps. An additional layer of scaling was added to get getGlobalScaleFactor() to be 1.0 for “normal” size which already includes the OS scale. This is similar to OSX where the OS itself does the hidpi scaling (it renders everything at x2 and scales the pixels down). The change makes setGlobalScaleFactor() behave more consistently.
If you do need the physical pixel scaling, there is getPhysicalPixelScaleFactor() in the graphic contexts.
I don’t think this is true. On Windows and Linux, the idea is that the only source of truth for the current scale in plugins is the value passed to AudioProcessorEditor::setScaleFactor. The desktop sizes will always be in physical pixels in this case, and the desktop scale will be 1.
ok… you have to know it obviously :). I just found at one point of the JUCE history I could remove my own additional scaling layer I added for windows plugins.
But… how can this work for multiple displays with potentially different scaling factors?
In this case, I believe the host is supposed to send each editor an appropriate scale factor to use, whenever the editor changes screens. This scheme does make additional windows (tooltips, popups, dialogs) a bit awkward to handle, as occasionally these additional windows are shown on a separate display to the editor that ‘created’ them. For this reason (and others!) it’s probably a good idea to keep the entire plugin UI inside a single view, and to avoid creating additional windows whenever possible.
the issue is for plugins, tested on vst2 and vst3
Ok seems like a similar issue to what I found. My specific issue was with FL Studio on Windows. I needed to know the actual OS scaling in order to know the size of a hosted plugin within our plugin, when showing it’s editor within our plugin window.
The changes I made are across these two commits in my fork:
I understand,
In my plugins I use two sets of images, normal scale and 2x resolution.
if the desktop scale is greater than 1 then I use the 2x images and then scale them to match the size of the gui.
I load the set of images into the constructor, and then draw them in component::paint()
So now I should modify everything so that it loads both sets of images “at constructor time” and then component::paint() decides which image to draw.
The question then is, will this behavior be maintained in future versions?
