This first shot is in the plugin browser - scale is hard to identify from this but you can tell it fits in the audio plugin host window and is hard to read.
FL studio has scaled the same as plugin host and looks good now, but the bounds haven’t adjusted as they have in plugin host.
So, same code, different results. I guess my question is, am I expected to check each host that I’m running in and scale/set bounds accordingly or should Juce be doing this for me?
FWIW, the too-small scaling in the JUCE Plugin Host under Windows has been that way for as long as I can remember (I am set at 1.5x scaling on a MBP running Bootcamp)… I always thought the scaling was stuck at 1 logical pixel = 1 physical pixel, aka the JUCE Plugin Host is ignoring Windows’ DPI settings when displaying plugin windows, but the strange scaling in the JUCE plugin host with scaling factor 2 is making me think otherwise(?).
Global Scale Factor is currently a disaster for Windows plug-ins. It mostly works on Mac, but it’s not intended for plugin use (yet). We had to do a pretty big workaround:
-Our PluginEditor is just an empty window.
-Our real editor is then added to this as a child component.
-The real editor is resized using AffineTransform scaling.
At the moment, there doesn’t seem to be a great solution for bug-free interface scaling that we’ve found. We’ve settled for AffineTransform with unscaled PopupMenus until that bug gets fixed.
Scale factors have always been a bit of a car-crash on Windows and behave differently in different hosts, and on different versions of the OS… Although juce UIs are scalable, we’ve always tried to avoid attempting to dictate how devs want their plugin to work, because people have different preferences.
Windows has horrible DPI handling.
The worst thing is lack of multiple (per display DPI handling).
I have here a 1080p display and 4k display that shows those strange behaviors. FLStudio on the 1080 shows fine but on the 4k it decides actually to become smaller with higher DPI.
Let’s hope Windows 10 RS3 will understand people need DPI to be per display. (macOS can have HiDPI and 1:1 resolutions pretty well).
hi Jules - i can see this is a bit of a messy problem, but it’s not just Windows here - setGlobalScaleFactor doesn’t work on OSX either inside plugins. I guess the real answer is that setGlobalScaleFactor cannot be used in plugins and you need to go the AffineTransform route…
Yeah, I’d recommend just scaling your own editor component. In a plugin there’s not really much concept of a global scale, as you really shouldn’t be doing things outside your own window anyway.
Hi, thanks for this - tried it today and it whilst it scales, the menu is only 1 row high and is pretty unusable and I seem to constantly be triggering an up or down movement…
Yeah I had a look into this last month and my only real discovery was that AffineTransforms are hard and make my head hurt. I’ll add this to the backlog though and dive into it again when some of the larger JUCE 5 features are out of the way.
Hi @ed95, wondering if there’s any new information on the currently recommended way to handle high DPI on Windows. There’s not a lot of definitive information on the forum, and it seems all over the map in the hosts we’ve tested so far. Any suggestions would be much appreciated.