Juce 8 bug - NativeScaleFactorNotifier callback not getting triggered

[fiedleraudio]

Hey folks,

again one on Windows 11.

When opening a DialogWindow with a NativeScaleFactorNotifier attached, the callback gets called with the correct scale factor when the window is opened from a standalone app/plugin but not when it is opened from a VST3 plugin.
Also when moving the DialogWindow between screens with different scale factors the behaviour is the same.

[fiedleraudio]

Ok, so here some news about this.

When commenting out the following two lines

    if (! isPerMonitorDPIAwareWindow (hwnd))
        return 0;

in juce_Windowing_windows.cpp, things start to behave correctly for that. I am not sure, what that will break in other parts but my tests have been promising so far.

This bug is related to:

Juce 8 bug - DialogWindow on Windows not scaling correctly

Hey folks, a DialogWindow opened from a plugin does not scale correctly when moved between screens with different scale factors. Visibly the window resizes but when checking it’s size in the resized() method, it’s logical size changes, which shouldn’t. That leads to the content being cut when moving a window opened for example on a screen at 150% to screen with 100%. Doing the same from a standalone app or standalone plugin seems to work. Checked on Windows 11 and VST3 (Reaper and Cubase 13)…

[reuk]

Thanks for your patience. We’ve now pushed some changes intended to address this issue. Please find further details here:

getScreenPosition ignores the scale factor in Cubase/REAPER on Windows

Thanks for your patience. We’ve now published a series of patches intended to address and improve this behaviour. This commit adds a new mechanism for overriding the platform scale factor detected by the ComponentPeer. Applications/plugins should generally avoid calling this function directly, and instead allow JUCE’s plugin wrappers to call this function when appropriate. This subsequent change updates the plugin wrappers to call the new ComponentPeer function. Plugins will use the detected…

[fiedleraudio]

Thanks! Much appreciated.

But the new changes introduced a new bug. Everything is working well until opening a Dialog Window and attaching an OpenGLContext to it on Windows.

If the window is opened on the same screen where the main app lives, everything is ok. But if you move the DialogWindow to another screen with another scale factor, everything gets garbled. The very same DialogWindow with exactly the same content but without the attached OpenGLContext shows no such behaviour.

More specifically, the OpenGL content gets partially shown with the scale factor from the screen where the main app is placed, while another part of the content is shown with the scale factor of the screen the DialogWindow has been moved onto.

[reuk]

Thanks for reporting this new issue.

Unfortunately I haven’t been able to reproduce the issue that you described so far. It would be helpful if you could provide the following information so that I can be sure that I’m addressing the problem that you’re seeing:

• Ideally, please provide a minimal program that demonstrates the problem. In particular, it would be helpful to see how the dialog window is configured (component hierarchy, gl context configuration, etc.).
• What are the specs (especailly GPU, GPU driver version, Windows version) of the machine you’re using for testing? If you have multiple test machines, do they all behave in the same way?
• A screenshot or screen recording would be helpful to demonstrate the misbehaviour.

If you’d prefer not to make this information public, you can instead email the JUCE team privately at info [at] juce [dot] com, or send us a private message on the forum.

While testing this behaviour I did see a potentially related issue, where OpenGL contexts spanning multiple displays with different scale factors could be drawn using a scale factor that differs from that of the containing window. I’ve got a fix in progress for this issue, but this sounds different to the problem that you described.

[fiedleraudio]

@reuk It actually sounds quite like my issue. Please let me know once the fix is available and i will test it on my end. If the problem still occurs after your fix i will send you all the info. Thanks for looking into it.

[fiedleraudio]

Hi @reuk , the latest commits fixed the problem on my end.

One question. Is there a reason for making the call in ScaleNotifierCallback in VST3PluginWindow async? I tested calling sync on Mac and Windows and haven’t found an issue so far. With async is still had resizing issues on Windows, but only with certain screen scales, for example with 125%, but not with 150%.

[reuk]

I’m afraid I don’t remember exactly why we switched to an async call here, but that’s been in place since 2022, and was added in this commit. As far as I can tell, the resizing behaviour was synchronous before this commit.

Plugin Hosting: Take custom scaling into account when computing editor sizes

I’m sure we made this change for a reason, but maybe the problem only happened under specific circumstances, e.g. when dragging the editor of a particular VST3 plugin between displays with different scale factors.

It would be helpful if you could describe the resizing issues you’re seeing (screen recordings are appreciated), and provide steps to reproduce the faulty behaviour.