UI scaling on Windows 4k

Hi, I’m getting different results running in different DAWS on 4k windows. Attached are some screen shots.

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.

The 2nd image is in Live and this is fine.

The 3rd image is FL studio and is equivalent to plugin host and is pretty much unusable.

The next 3 images are setting the global scaling factor to 2:

Plugin host is now fine.

Ableton has gone super sized

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?

Same behaviour seen on the demo plugin…


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.


interesting… thx for the suggestion

from what I remember though when I last tried using the AffineTransform none of the combo boxes were scaled and remained tiny…


Yep! They’ll scale “correctly” if you override the following in your LookAndFeel:

Component* UALookAndFeel::getParentComponentForMenuOptions(const PopupMenu::Options& options)
	if (PluginHostType::getPluginLoadedAs() == AudioProcessor::wrapperType_AudioUnitv3)
		if (options.getParentComponent() == nullptr && options.getTargetComponent() != nullptr)
			return options.getTargetComponent()->getTopLevelComponent();
    if (options.getParentComponent() == nullptr && options.getTargetComponent() != nullptr)
        return options.getTargetComponent()->getParentComponent();
        //return options.getTargetComponent()->getTopLevelComponent();
    return LookAndFeel_V2::getParentComponentForMenuOptions(options);

But then you run into a different issue…

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.

1 Like

Lovely - thx for the info, much appreciated!

Any comments from the Juce developers on why scaling is left for the dev to handle? 4k screens on Windows have been around for a number of years now…

bumpety bump bump…

After checking the setGlobalScaleFactor() on OSX plugins, it’s pretty broken there too.

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.

1 Like

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.

yeah, that makes sense. thx.

Hi, so I’ve been trying the affinetransform route and combos don’t get scaled, messagesboxes don’t get scaled, tooltips don’t get scaled.

I know you said you wanted to leave these things up to the individual to decide on, but I’d have thought everyone would want these?

I’m not sure how to go about scaling all these individual elements in the most effective way… Maybe there should be a tutorial?


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…

Is there any way round this? thx

@ed95 recently did a lot of work to get this straight on Windows, maybe he can comment…

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.


ok, thx… I’ll pester you again a bit after 5 is out :wink:

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.