Win10 Live11 vst3 HDPI GUI OpenGL scaling issue

[thirio]

• A new basic plug-in project vst3 appears pixelated in Ableton Live 11 on Windows 10 with a >100% Display scale by default. (A)

• Disabling Auto-Scale Plug-In Window in Live solves this issue. (B) But it gets worse when using OpenGL. (D)

I’ve used Projucer’s develop branch hoping that the last few vst3 host size and scale commits would solve this issue. And tested it with Live 11.0.10.

C,D

openGlContext.attachTo(*getTopLevelComponent());

added to PluginEditor constructor.

scale/dpi

const auto scale = juce::Desktop::getInstance().getDisplays().getDisplayForRect(getTopLevelComponent()->getScreenBounds())->scale;
const auto dpi = juce::Desktop::getInstance().getDisplays().getDisplayForRect(getTopLevelComponent()->getScreenBounds())->dpi;

DBG("scale: " + juce::String(scale) + " dpi: " + juce::String(dpi));

added to PluginEditor resized()

[reuk]

The behaviour when not using OpenGL appears correct. “Auto scaling” means bitmap stretching, so when auto scaling is on, all plugins will appear blurry/pixelated on hi-DPI displays. As a quick test, I tried loading Surge (a non-JUCE VST3 plugin) and this also appears blurry when auto scaling is enabled.

Regarding the OpenGL issue, I just tried modifying the CMake/AudioPlugin example project to use an OpenGL context. The context is a member of the AudioProcessorEditor, and I call context.attachTo (*this) at the end of the constructor. Opening the plugin window on a display with a scale factor of 175% and auto-scaling disabled works correctly in Live 11.0.11.

Do you get different results when you open and close the editor window a few times, or if you wait for a few seconds after opening the editor? Although the editor opens in the correct state for me, I noticed that the window size sometimes changed incorrectly when moving the editor between screens with different scale factors, and needed a few seconds to sort itself out. Again, I saw the same behaviour when I tested with Surge, so I don’t think this is a JUCE issue.

If you have any other Windows DAWs, it’s worth testing your plugin in those too. If you see the same issues in all DAWs, it’s likely that the problem is in one of the components shared by all of the tests (e.g. JUCE or your graphics card drivers). If you only see problems in Live then the issue is more likely to be in the DAW itself.

[thirio]

Thank you for your quick reply! I did have the OpenGL GUI snap into a correct scale after a while with a window focus change or resize. It’s hard to say exactly when this will happen. Then when reopening the plugin it would initially be stretched and snap correct when moving the plugin window.

Other DAWs: In Reaper and FL Studio it works like a charm. In Renoise 3.3.2. demo the plugin view within the window looks half size and half res. I’m not that familiar with Renoise and it seems it ignores the windows display scale setting completely.

I’ve just updated Live to 11.0.11 and built my project with the develop branch and the issue remains. I’ve also moved context.attachTo (*this) to the end of the constructor, but it made no difference.

[phraemer]

@thirio

Then when reopening the plugin it would initially be stretched and snap correct when moving the plugin window.

We have the same issue in Live 11 on Windows with “Auto-scale plugin windows” off.

We attach the same way and have a 30hz timer which calls repaint()

But only tabbing away and back or some other kinds of focus change trigger things to paint correctly.

Is there something I could do to help us all diagnose this issue?

The fact that it can be repainted correctly at least suggests we could figure out a workaround, even if ultimately it turns out to be a DAW issue. Although I’d love to confirm that it’s definitely a Live 11 issue only.

[phraemer]

I’ve created a complete working example to help diagnose this issue and hopefully find a fix or workaround.

GitHub - phraemer/jsjucegl: JUCE basic plugin that uses OpenGL and timed...

And an issue with gifs demonstrating the scaling problem in Live 11

OpenGL painting in Ableton Live 11 on Windows isn't always scaling correctly

[thirio]

Well, at least I can confirm that it’s not just Live with ogl issues on win10. Renoise has similar problems: pixelated AND scaled down.

[reuk]

I tried to reproduce this issue with Live 11 Lite 11.0.12, on Windows 11 21H2, using the linked project. The window sizes correctly with both auto-scaling settings here.

After switching off auto-scaling, Live warned me to delete the plugin and reload it. Did you definitely remember to do this when testing?

[phraemer]

Hi @reuk!

Yes definitely did the delete and re-add steps.
One thing I should have noted, I have my DPI scaling for Windows at 200% (large 4k monitor)
Are you trying with anything other than 100% scale?

[thirio]

Could it be a gpu manufacturer/driver issue? I’m on a NVIDIA GeForce RTX 2070 Super. Driver version: 472.47

[reuk]

I was testing with 125% scale, but I’ll give 200% a quick go.

Edit: 200% scale on an XPS 13 with Intel Iris Plus graphics works too:

[phraemer]

@thirio I’ve tested on Intel HD 530, Nvidia GTX 960 and an AMD Radeon Pro 455

All on Windows 10
We’ll check on a Windows 11 machine too next.

[phraemer]

This is a real head-scratcher.

At any dpi scaling other than 100% it’s pixelated for me and I can see the on-hover highlighting of the button when I move over it with the mouse only occurs where you would expect the button to be drawn, i.e. smaller than what it’s visual appearance is (I hope that makes sense)

[reuk]

I just pushed some fixes for some data races we were seeing on macOS on the viewportArea and scale members of the openGL context. Perhaps the issue is due to very unlucky timing (unlikely, but worth testing). Could you try updating to the very latest develop branch and check whether you see different results there?

OpenGL: Avoid races on viewportArea and scale data members

[phraemer]

Tried the develop branch. Same issue. Was worth a try!

[phraemer]

scale_fix_on_focus.zip (1.5 MB)
log.txt (3.8 KB)

Maybe someone is interested in this, maybe not but I’ve simplified my test plugin.
Now what it does is 5 seconds after you click on the button it detaches and reattaches OpenGL and then you can see the incorrect scaling.

On my various machines, and only after a couple of minutes or so of it running, switching focus from the plugin and back again results in the correct scaling.

After that happens the first time, doing the detach/reattach thing again will once again scale incorrectly but focus switching now fixes it immediately.

Obviously this isn’t happening on everyone’s machines, so to prove I’m not crazy I made a video (attached)
In a desperate attempt to find something, anything to guide me to an explanation, I littered the JUCE code with DBG lines which you can see in the Output windows of VS.
I’ve included that output as a txt file too with markers showing where what is happening in the video.

I’ll continue hunting for a workaround.

[thirio]

Just spotted this in Ableton’s Live 11.2b5 Beta Release notes, haven’t tested it yet, but it reads promising:

Improved high DPI support for VST3 plug-ins on Windows:

• Plug-ins that support high DPI and IPlugViewContentScale should be the correct size.
• Plug-ins that have their own resizing logic should not resize when the user drags the window around.
• Plug-in windows are instantiated with the correct size in both scaled and non-scaled modes.
• Plug-ins that support host-initiated resizing are interrogated by calling checkSizeContraint in the correct place.
• Plug-ins that support host-initiated resizing can be maximized by double-clicking on the title bar.

[olilarkin]

FYI. The changes don’t yet address the bug you are seeing. The issue with JUCE VST3 plug-ins using OpenGL is still present in Live 11.2b5 with some GPUs.