High dpi issue on Windows with VST3 plugins

Hey there!
When using Wavelab 10 or Reaper 6 on Windows 10 with a display scale factor of 125% (and probably higher), vst3 plugins built with JUCE 5.4.5 (release and latest dev) appear with a wrong window size.

The gui rendering scale factor is correct, but the window always has the size it would have with a display scale factor of 100%. Thus, the content gets truncated right and bottom because the window is too small.

This happens with an empty projucer template plugin.

Only vst3 is affected, vst2 works fine (including dpi scaling).
vst3 behaves correctly in Cubase 10.

Can anyone confirm this? Any ideas how to fix this?

This is what it looks like in Reaper 6.02:

(Text should be centered!)

Same here!

Had a similar problem before. For REAPER, try all the various alternatives for the HiDPI mode (see screenshot), one might be the one that does the right thing.

You need to quit and restart REAPER after every change to that setting in order to see a difference.

At the moment I have a strong feeling that it’s a bug in JUCE regarding the general handling of VST3 in highdpi environments. I’ll try to test more highdpi capable VST3 hosts today and let you know about my findings.

I observed that within the JUCE VST3 wrapper, there are explicit “workarounds” for Cubase 10. The process of instantiating and opening a VST3 plugin leads to a lot of calls of the related functions, not so easy to find out what’s actually happening and in what order, so I haven’t been able to figure it all out within the JUCE code yet. I’ll keep trying though.

Probably related: Cubase 10 HiDPI, Windows and OpenGL

High DPI is getting more popular on Windows, general support has become better, and more hosts start supporting it as well as VST3. I’m beginning to get complaints from customers (at the moment recommending to use the VST2 versions instead), so this is getting more and more critical…

We’re seeing this issue as well in REAPER 5.92, VST3 only (VST2 works fine). Ableton Live is ok on the same test machine.

VST3 Scaling in Bitwig3/Windows works too…

I cluttered juce_VST3_Wrapper.cpp with Logger calls and tried to get of the bottom of this.
Each and every DAW has a very particular flavor of “when calling what” during plugin setup, it’s far from consistent.

Interesting observations: Bitwig and FL Studio call setContentScaleFactor with the display scale factor, Cubase10, Wavelab and Reaper do not (always appears to be 1).

For Cubase 10 and Fruityloops, there is a “hack” in the VST3 wrapper: The factor given to setContentScaleFactor is being overridden by peer->getPlatformScaleFactor().
I added Reaper and Wavelab there, just out of curiosity. For Reaper 6, the same trick appears to work as well. For Wavelab, it doesn’t (just leads to more overall scaling).

I still have the feeling that the whole process of setting up the different scalings (host window, screen scale, component scale, etc) should be tackled on a more fundamental level. Even if I’d find a hack/workaround that works for Wavelab too, that would only mean that on my system the hosts I have available work. But it doesn’t feel right.

JUCE devs, would you mind chiming in here?

BTW: Cleanest plugin init call trace I’ve seen was with Bitwig, worst one with Cubase 10.
BTW2: going purely from the comment in the VST3 SDK, it’s not really clear whether setContentScaleFactor should be called for handing over OS/DPI related scale factors to a plugin, or whether a plugin should handle OS/DPI scale internally, and setContentScaleFactor should be used for applying “additional scale”. This might explain why hosts behave differently in that regard…

If anyone is interested, I’m attaching my call traces/log output. Process was always “start host, load plugin, open plugin editor, close plugin editor, close host”.

VST3_JUCE_LOG_20200114T115211.193 0100_Wavelab_Wrongscale.txt (5.6 KB)
VST3_JUCE_LOG_20200114T115409.498 0100_Bitwig_Correct.txt (6.4 KB)
VST3_JUCE_LOG_20200114T115605.919 0100_Cubase10_Correct.txt (14.0 KB)
VST3_JUCE_LOG_20200114T115823.872 0100_Reaper6_wrongscale.txt (7.9 KB)
VST3_JUCE_LOG_20200114T121133.020 0100_FlStudio20_Correct.txt (6.7 KB)

1 Like

I had a report of this exact problem as well. Confirmed that VST scales the UI and window size correctly while VST3 scales the UI but not the window size. Exactly as in @jcomusic’s earlier post. Tested using Reaper 6.02 and 6.03.

Switching JUCE_WIN_PER_MONITOR_DPI_AWARE to Disabled stops anything from scaling (so is potentially very small) but at least means none of the interface is outside of the window.

So you are saying that Reaper always calls setContentScaleFactor() with 1, regardless of what is set in its HiDPI mode setting that I mentioned in my previous posts?

It sounds very strange, I’d expect that setting to play a part in that, unfortunately I don’t have time at the moment to check that myself

Reaper has not yet implemented the setContentScaleFactor().

I’ve added a feature request over at their forum Support Steinberg / Presonus VST / VST3 HiDPI extensions, but it seems it has gone under the radar.
If some of you +1 this it might get Justin’s attention :wink: