Bug: When attaching an OpenGLContext to plugin, the whole UI is scaled wrong in VST2/VST3

To improve rendering performance, we attach an OpenGLContext like this:

openGLContext.attachTo ( *getTopLevelComponent () );

within our constructor for the PluginAudioEditor.

If we do that, our plugin is displayed incorrectly, with the graphics scaled up (probably by my monitor scale-factor of 150%) from the bottom-left corner upwards. Mouse interaction is visibly offset by a large amount.

If we don’t attach the OpenGLContext, everything renders correctly.

This does NOT happen in stand-alone mode, only when loaded as a VST2 or VST3 in Cubase 10 (Windows 64-bit). Haven’t tested other plugin formats.

When changing my desktop scale to 100%, everything works correctly.

Can confirm this happens, also in FL Studio 20.5.1.

With some quick debugging, as fast as I could before deadlocking my entire system with GL + FL + my plugin in a bridged mode, getWindowScaleFactor reports the wrong scale in updateViewportSize.

Has this begun recently? I pushed a commit setting the DPI-awareness of the OpenGL worker threads a few days ago here which might be the culprit. Are you able to test before and after this commit to see if it’s causing the problem?

I’ve switched to a revision from a week ago (right before you made that change) and first I was disappointed, because it looked identical, but then, after around 1-2 seconds later it redrew itself at the correct scale.

So without that fix from a week ago, it’s first scaled wrong, but after around a second or two, it refreshed (could have something to do with a “repaint” that I call once another background task completes).

I remember that before this, the scale was also always wrong, until I moved the window with the mouse and thus forced a repaint.

Hmm, I can’t reproduce this in Cubase 10 or FL Studio 20. My desktop scale factor is set to 175% and I’ve tried running Cubase with hiDPI enabled and disabled, and FL Studio with global scale set to “system” and other values… It could be a graphics card specific issue which will be hard to track down, but could you also try with the following modifications to the setThreadDPIAwareness() method in juce_gui_basics/native/juce_win32_Windowing.cpp at line 4098 -

JUCE_API void setThreadDPIAwareness (void* hwnd)
    if (setThreadDPIAwarenessContext != nullptr)
        if (! JUCEApplicationBase::isStandaloneApp())
            if (hwnd != nullptr && getWindowDPIAwarenessContext != nullptr)
                setThreadDPIAwarenessContext (getWindowDPIAwarenessContext ((HWND) hwnd));
            setThreadDPIAwarenessContext (DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE);

I can try on my Intel GPU on my laptop at some point today and get back to you.

My test from my previous post was done on the latest NVIDIA GeForce driver at the time (436.30), using my GTX1080.

1 Like

Could you be more specific what you mean? Can’t reproduce the wrong scale being used or the first paint is wrong, then it corrects itself?

Using Nvidia 1060 and zero problems with any other apps.

Both, I’ve built the AudioPluginDemo as both VST2 and VST3 and it’s rendering as expected in Cubase and FL Studio.

With an openglcontext attached?

Yes, it renders correctly both with and without an OpenGLContext attached. Are you able to reproduce the issue by just adding an OpenGLContext to the vanilla JUCE AudioPluginDemo and calling attachTo()?

The demo plugin with an OpenGLContext attached renders correctly, but strangely NOT when opened for the first time.

So you start Cubase 10, load the AudioPluginDemo as a VST3 instrument, and when opening the GUI it looks like this:


Then, when only changing the height of the window, it looks like this:


You can clearly see the cropping and how badly upscaled everything looks (pixels are scaled by 150% without even linear interpolation)

After increasing the height (or width) further, suddenly the whole GUI corrects itself and renders correctly:

Before the “fix” a week ago, and with our plugin, it worked just way better.

Did you try with the change I posted above?

I’ve just made the change you described above (copy’n’pasted the entire block) and it makes no difference for our plugin in Cubase 10 (didn’t test with the AudioPluginDemo).

It worked really better before you made the change a week ago for “Cantabile”, a host nobody ever heard of and not used by a single customer of ours we are aware of, while it broke compatibility with Cubase, a major host on the market.

I highly doubt it’s a graphics-card specific issue. The Nvidia cards we use are extremely popular and we have exactly zero graphical issues otherwise.

Again: it worked fine a week ago. It broke with the commit that fixed the issue in “Cantabile”.

What does this even mean? It’s either it works as expected or it doesn’t.

It’s not always so cut and dry. It worked better, as in it displayed with the wrong scale for about a second and then redrew itself correctly right after.

I’m having this exact issue with JUCE 6.0.5 now.

In rare cases moving the windows, opening the start menu or alt-tabbing “magically” fixes the rendering. This is very random though. I get a strong feeling that this might even be a windows or a gpu driver issue… regardless of that, I urgently need some sort of work around. Experimenting with window creation and dpi awareness setters now :confused: