Wrong window size when moving VST3 between displays

Hello, there seems to be a bug on Windows when moving a VST3 between different displays with different DPI’s.

I have 2 displays. The main one is at 200% scale. The second one is at 100% scale. When I move a VST3 from the main display to the second display the Window will end up double size.

This is easily reproduced using the Examples/Cmake/AudioPlugin project from JUCE 6.1.6.

In Bitwig after moving the plugin all the extra space will be filled with a gray background and the main component is positioned on the top left (screen shot attached).

In Ableton the main component actually gets resized too.

Let me know if I can provide any more information to help fix this.

There are a few other reports around this area that look to be related. Sorry if this is actually a repeat.

I tried the following:

  • Checked out JUCE 6.1.6
  • Built the CMake Audio Plugin Example
  • Set laptop (primary) screen scale to 200%, and external screen scale to 100%
  • Launched Bitwig 4.2.0, then opened the Audio Plugin Example on a track

The plugin window opens at the correct size, and remains scaled correctly when dragging between screens. I also tested briefly with Bitwig 4.1.6 and the JUCE develop branch, and that seemed to work correctly too. I also tried switching the primary/secondary displays and testing again, and got the same result.

Is it possible that you’re using an older Bitwig version, and that this issue was resolved in a newer version?

I also noticed that right-clicking on the plugin in the Browser view on the right-hand side of the window provides the option to “Stretch the Plug-in Window to Match DPI”. Have you tried adjusting this setting, and did you notice any changes in behaviour? For me, it doesn’t seem to have any effect at all, and I can’t find the option mentioned in the user guide, so I’m not exactly sure how it’s supposed to work. Perhaps it doesn’t do anything if the plug-in supports scaling natively…

Clutching at straws here, but there’s a very tiny chance that this is related to the OS version you’re using. I’m testing on Windows 11 21H2, and unfortunately I don’t have easy access to a Windows 10 computer at the moment. If you have access to another version of Windows, it might be worth testing there too.

Hey @reuk, thanks for such a quick reply.

You’re right I was on an older Bitwig version (3.x) - after updating to 4.2 I can’t reproduce the issue. Sorry I didn’t think to try that before reporting it!

However I can still see issues in Ableton where I am on the latest version (11.1). Strangely it’s happening less frequently after restarting my computer. I have to change display 5 -10 times before I see the bug.

I’m a bit busy for the rest of this week, but I can retest this more thoroughly next week and provide better information, screenshots, etc.

I’ve just tested a bit with Live 11.1 on a Windows machine with a couple of displays at different scale factors.

Live doesn’t use the plugin’s resizing methods in the way that I’d expect:

  • It never calls setContentScaleFactor on the plugin’s UI, so the wrapper has to check the current display on a timer and update the current scale factor when necessary.
  • It calls canResize on the plugin view after opening it, but doesn’t seem to respect the result of this call. According to the VST3 documentation, a host is supposed to only call checkSizeConstraint during a live resize operation (which should only happen if the plugin reports it can resize), but Live calls this function every time the user drags the editor. It also passes the result of this function to onSize, whether or not checkSizeConstraints reported success.
  • When dragging an editor between displays, Live will continue to call checkSizeConstraint and onSize with the editor’s old size in physical pixels. In some cases, JUCE’s “scale factor check” timer callback fires, resizes the view to the correct size, and then Live asynchronously calls onSize again with the editor’s old size in physical pixels, resulting in the editor being set to the wrong logical size.

The result of all of this is that sometimes the plugin editor’s logical size can be set incorrectly after dragging it between screens, although the contents of the editor remain scaled correctly for the current display.

I think we can add a workaround for the case of non-resizable editors by ensuring that the result of checkSizeConstraint always takes the current scale factor into account.

For resizable editors, things are trickier, because the host may legitimately call checkSizeConstraint to trigger a host-side live resize. I think the best you can do in this situation is to ensure that your editor has a constrainer set on it that will enforce the minimum/maximum editor sizes. Unfortunately, the editor may still change logical size when moving it between displays, but the final editor size should still be ‘valid’ for the editor. I tested by adding this to the constructor of the AudioPluginExample:

setResizable (true, true);
setResizeLimits (400, 300, 600, 450);

Now, although the logical size of the editor sometimes changes when switching displays, it always remains within the resize limits.

FWIW the Live workaround is here: