FabFilter VST windows don't resize correctly on initial open on non-100% DPI

[KLszTsu]

Operating System Info

Windows 10

Other OS

No response

OBS Studio Version

Other

OBS Studio Version (Other)

OBS 26 and above, including 27.2.0-rc1

OBS Studio Log URL

https://obsproject.com/logs/pmNFddnzLY3h8Jia

OBS Studio Crash Log URL

No response

Expected Behavior

Current Behavior

Steps to Reproduce

1. Add a VST audio plugin - tested with FabFilter and d16 group plugins.
2. Open plugin interface

Anything else we should know?

No response

[WizardCM]

I cannot reproduce this in "any audio plugin". I spent a lot of time recently familiarising myself with how Qt and VSTs resize

• Especially #102 and 56168fdff9f61d630c8425380d3b99211951a376 but also 95d81a3377c44736bc3a79d290adfc9480fdd3d7

Your log explicitly mentions VST plugins "FabFilter Pro-C 2" and "FabFilter Pro-Q 3" - I've updated the ticket description & title to match.

I have downloaded both and I will test this later.

[WizardCM]

Additionally, what DPI is your monitor set to?

[KLszTsu]

Additionally, what DPI is your monitor set to?

Yeah. That seems to be where the problem is at. I was at 125% and by setting it back to 100% will it renders properly.

[WizardCM]

I feared that would be the case. 26 is around the time we properly started reporting to the operating system that OBS handles DPI correctly, but it seems VSTs don't and the window size calculation doesn't take that into consideration. I believe we handle this somewhere else too.. maybe in the browser code? I will have to do some digging.

[WizardCM]

Note to self: https://github.com/obsproject/obs-studio/pull/4755/files#diff-4c0a52244f264feca9c3031c90edcbbbd1087a3040c15f9df4ca9700c5154fa3R4676-R4679

Combined with https://stackoverflow.com/questions/49167204/find-screen-a-qwidget-is-located-on

[WizardCM]

Right, so firstly I can confirm OBS + High DPI + VSTs don't work well together.

Secondly, I'm having trouble fixing this. This documentation provides an example that should work perfectly with our code, however it results in Qt not correctly repositioning the resulting window (that is - it doesn't sit within the container, just gets locked at 0,0).

Example suitable for us:

The code change I made:

diff --git a/win/EditorWidget-win.cpp b/win/EditorWidget-win.cpp
index e3f05e3..3bb09d6 100644
--- a/win/EditorWidget-win.cpp
+++ b/win/EditorWidget-win.cpp
@@ -28,8 +28,10 @@ void EditorWidget::buildEffectContainer(AEffect *effect)
        RegisterClassExW(&wcex);

        const auto style = WS_CAPTION | WS_THICKFRAME | WS_OVERLAPPEDWINDOW;
+       DPI_AWARENESS_CONTEXT previousDpi = SetThreadDpiAwarenessContext(DPI_AWARENESS_CONTEXT_UNAWARE);
        windowHandle =
                CreateWindowW(wcex.lpszClassName, TEXT(""), style, 0, 0, 0, 0, nullptr, nullptr, nullptr, nullptr);
+       SetThreadDpiAwarenessContext(previousDpi);

        // set pointer to vst effect for window long
        LONG_PTR wndPtr = (LONG_PTR)effect;

And the end result:

If I move the SetThreadDpiAwarenessContext(previousDpi) call anywhere later, then the VST window just never renders.

I have a feeling both of these are Qt bugs, but I'm not 100% sure.

---

Additionally, with these changes there are certain VSTs that continue to behave incorrectly. If we get the above code working, I would be OK with providing a toggle in the VST properties allowing the user to disable VST DPI code if necessary.