High dpi issue on Windows with VST3 plugins

[jcomusic]

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?

[jcomusic]

This is what it looks like in Reaper 6.02:

(Text should be centered!)

[gustav-scholda]

Same here!

[yfede]

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.

[jcomusic]

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…

[tlongabaugh]

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.

[jcomusic]

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)

[pstitt01]

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.

[yfede]

@jcomusic

and Reaper do not (always appears to be 1).

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

[lorcan]

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

[pstitt01]

This looks to have been fixed in the newest dev version of Reaper according to a post in the Reaper FR forum!

[jcomusic]

Hey guys! Still diving deep into the bottom of the JUCE vst3 wrapper and win32 windowing systems. It’s beginning to get clearer.

• First, as I already mentioned, it is not clear that setContentScaleFactor is supposed to hand through the windows dpi scale factor. The VST3 SDK is vague in that regard, but it’s interesting to see that most recent Cubase and Wavelab report a factor of 1. If Steinberg has it correct, this scale factor from the VST3 callback should be applied in addition to the operating system dpi scale factor.
• Problems with the observed plugin window truncation arise whenever the editor scale factor being determined in the VST3 wrapper is different from the operating system scale factor.
• The operating system scale factor is determined elsewhere, outside of the VST3 wrapper.
• You can retrieve the operating system scale factor from ComponentPeer, which represents the actual OS window which contains the plugin.
• There is even additional code for additional scaling of the content component in ComponentPeer, if their sizes don’t match.

Following those observations, the host window should always be resized to:
PluginEditorWindowSize (logical units) * combinedContentScaleFactor

With combinedContentScaleFactor being the OS scale factor, which can change if you move the window from one screen to another (not testing this yet!).
If my assumptions about VST3::setContentScaleFactor are correct, this has to be handled completely differently.

I will now try to rewrite portions of the VST3 wrapper in a way that disregards setContentScaleFactor entirely and always uses the OS scale factor to scale the host window. Just to see what happens.

[jcomusic]

Sorry, I read the comment in the VST3 SDK again: the VST3 setContentScaleFactor callback is indeed meant to communicate system changes as well, but allows for applying different scale. This fully explains why we need workarounds.

In any case, truncation must not happen, host window size must always be set to editorComponentSize * whateverScaleFactor is being used for rendering.

[jcomusic]

This indeed appears to work with all the hosts I have here for testing!

What I did:

• setContentScaleFactor(…): Always get scale factor from component peer (if available), disregard what is given in the callback, because we can’t rely on it. This is code that was already in place for Cubase 10 and FL studio, but now I’m always doing it.
• resizeHostWindow(…): Removed workarounds for also setting component size (setBounds(…)) for Wavelab and Live on windows. Now it simply (and only) does what I suggested, setting owner.plugFrame to pluginEditorSize * scaleFactor.

I will now investigate how this behaves with a multi monitor setup involving different scale factors. Also, I obviously can’t exclude that this might cause issues with other host/os combinations.

[jcomusic]

Turns out, this doesn’t solve the issues with multi monitor settings / different dpi per screen. It’s very much broken, with or without my fix attempts (in Cubase 10 and Wavelab).

Now trying a completely different approach, disabling per monitor dpi in project settings and doing it all myself (getting a device context, figuring out display scale factor, checking for peer size / component size mismatches, etc).

The idea is manually forcing the right scale with juce::getInstance().setGlobalScaleFactor(…). Applying the scale works, but sadly using this method, the plugin host window will not be resized correctly.

I’m running out of ideas (aside from spending days or weeks rewriting half of JUCE). Is there really noone here who managed to somehow fix the vst3/high dpi issues for a plugin?

[kunz]

Did you use the default constrainer (getConstrainer()) or did you set yours in the plugin editor? It looks like the host want’s to scale the plugin itself and i noticed that this only happens when the constrainer is set or if you are using the default constrainer.

I will also have a closer look at the issue. I also received some user reports regarding this.

[jcomusic]

Hey, I sadly had to leave the issue alone for the time being and take care of more pressing matters. Also, my Wavelab trial ran out

I still think it boils down to some hosts telling the VST3 to scale with the windows screen scale factors, others (like Wavelab and Cubase) just give it a scale factor of 1.0 no matter what. Cubase works because there is a workaround in place, wavelab doesn’t.

For investigation, just use a barebones Projucer template plugin project and use a windows 10 system with a screen scale factor of 125% (bonus task: add a second screen with a different scale factor). setContentScaleFactor and resizeHostWindow are the interesting places to look at.

I haven’t tested yet if anything changed/improved with JUCE 5.4.7 over 5.4.5.

Please let us know if you can figure something out

[OBO]

It even doesn’t work if JUCE Plugin Host is the host! Please see:

Plugin hosting DPI scaling issues / OpenGL

My own juce plugin has scaling issues in juce plugin host, both with and without DPI awareness toggled. As a sanity check I tested with the most popular free compressor (AudioDamage RoughRider 2), inside Juce Plugin Host, - both master and dev branch. It looks like this on Windows with 150% scale monitor. Without DPI awareness: [image] With DPI awareness: [image] I think this scaling and offsetting is happening with all plugins that use OpenGL. Anybody can shed further light on this?

[kunz]

I don’t use open gl. I wasn’t able to reproduce this on windows with my parallels windows VM and 150% scaling. I think it happens only under some special conditions i don’t know yet.

[jcomusic]

Last time I checked the issue didn’t occur when using the JUCE plugin host. Probably something else in your case?