UI scaling on Windows 4k

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.

Bumping this. With the impending release of Ableton 10 and HiDPI mode, this is now more important.


Windows introduced a per display DPI setting some years ago already (I think with Windows 8.1), but this needs support from applications — i.e. they have to respond to WM_DPICHANGED messsages. This is not supported by JUCE.

I tried to patch JUCE a while ago, and dynamically changing the desktop scaling factor of a window seems to work well, however I didn’t figure out how to change this scale factor and at the same time move the window to the suggested position.

No, that’s not true!

We do fetch the DPI for each display when building the list.

I’m referring to automatically changing the DPI setting on a window when moving between screens. That is reported with a WM_DPICHANGED message. Juce isn’t doing much in response to that message, see juce_win32_Windowing.cpp.


JUCE is currently system DPI aware on Windows meaning that the DPI of the primary monitor is used to scale all windows on all monitors and it doesn’t receive WM_DPICHANGED messages. I’ve had a quick look at changing this to be per-monitor DPI aware meaning that we get the WM_DPICHANGED messages, but figuring out how to respond to them correctly and resize/rescale everything is a big task. I’ll add it to our backlog.

Assuming someone is working on this at Roli, please be aware of the following:

In order to accurately test this, you need to set Windows global scaling to something besides 100%. The most common setting for 4K monitors is 125%. This results in a mismatch between what the app (either Studio One 3 or Live 10 < b7) thinks the DPI is and what the DPI actually is.

The net result is different in the two apps, but it is bordering on comically problematic in Studio One 3.

As far as I am aware, Studio One 3 is the only currently available truly HiDpi host on Windows. Bitwig purports to be, but they just do pixel doubling like Live 10, so the net result is a plugin that is just drawing at 96dpi but upscaled. This is the method Ableton went with for the public beta of Live 10, and considering the massive problems they were having, I don’t expect a change any time soon.

Has there been any updates on this? I’ve ran into this issue on my MBP with bootcamp Windows installed (which defaulted to 200% scale when first installed).

We also have a Studio One customer reporting this issue.

Bumpety Bump Bump!

I’m experiencing this issue in Windows 10 on my 4K monitor and a Surface Pro. Has there been any development with this? My plugin scales correctly without using an affine transform or global scale factor but all my submenus (popups, combobox, etc.) are not scaling correctly.

In the meantime a whole new scaling system on windows was added, see the release notes here:

If you experience problems with the current version, it’s probably the best to open a new thread and let this one rest in peace.