We’re seeing issues with OpenGL plug-ins built from the latest develop tip of JUCE running in Cubase 10.0.10 with HiDPI switched on, Windows 10.
Drawing is not correct: the GUI is incorrectly sized and/or it appears as if two of the GUI have been drawn in the window at different positions.
System has multiple screens, with the primary display at 3840 x 2160 scaled to 150% and all other screens at 100% scale. The drawing looks different on displays with different scale settings, but is always incorrect.
Below is a PIP that demonstrates the issue.
OpenGLPlugIn.h (5.8 KB)
Did you already have a look at these two threads?
I have @McMartin, and without an
OpenGLContext attached the GUI content appears as expected. The window size is initially incorrect - as if Cubase is setting the dimensions using the primary monitor’s scale settings - but I don’t believe that is JUCE’s problem. Dragging between monitors fixes the window size and the content is always drawn correctly without OpenGL.
OpenGLContext attached, however, the GUI content is as described in my previous post. The window size behaviour remains the same (again, this is probably not JUCE’s fault) but the content is drawn incorrectly.
I built my example before and after the commit below, but unfortunately didn’t see any change to how the content was being drawn.
Has anyone managed to reproduce this yet?
I’ve just pushed a few commits to develop (notably ada0a05, 87cf4d2 and 7134bd0) which should address these issues. Let me know if it fixes things for you.
Thanks @ed95, that has helped, however there are still some problems.
On the 150% scaled screen, the content is now correctly positioned, but still too big (looks like 200% content in a 150% window).
When opening the GUI from a closed state on the 150% screen the window dimensions are correct. But, when opening it from closed on the 100% screen the window dimensions are still 150% (same as the primary monitor), although the content is the correct size, so there is a white gap to the right and bottom.
I’ll do some debugging to see if I can provide any further information.
IIUC, Cubase got only whole scales (also looking at develop vst3_wrapper code).
if this is declared by the plug-in so maybe using floor instead of round would be better?
I’ve debugged and played around with different parts of the code for many hours now and I still can’t figure out what’s going on here.
Add some text to the GUI and it’s clear that the OpenGL frame buffer image is being stretched at anything other than 100% scale. I checked that the frame buffer itself is drawing correctly by drawing everything into an image file. That comes out perfect at the correct, scaled dimensions.
Dividing the viewport by the scale before drawing it makes the content fit correctly in the window but then it’s obvious that it is being scaled down.
@ttg I tried swapping the calls to
round() with calls to
floor() but that didn’t seem to help. I’ve tried setting the monitor to 200% scale and that is just as bad.
This is driving me nuts.
Bumping this. We’re seeing this in Cubase 10 using the latest JUCE develop. Ableton 10 (latest beta) seems fine, though. I tested Ableton with VST2 and VST3.
EDIT: After more testing, I was able to get Ableton 10 to have broken HiDPI scaling as well. You have to use the VST2 version of the plugin. Right-click on the plugin and disable “Auto-Scale Plugin Window”
Anyone else seeing this on latest?
Just bumping this. To me it looks like a double-scaling thing happening somewhere in the chain. Like the host/system is scaling up the GL context when it renders but then JUCE/system/host/something is scaling it a second time to “correct” for the difference and that’s why it appears oversized. Seems like specifically NOT doing that second scaling might just fix the issue but if it’s on the host end then it’s tricky and/or we’d have to figure out which ones are doing it and how. The fact that we see similar but slightly different behavior on Cubase vs. Ableton is particularly troubling.
I’m not seeing this, the following is a screenshot of Cubase 10 running on Windows 10 with a scale factor of 150% where the plug-in on the right has been rendered with OpenGL and the left without:
They both look correct to me.
However, I have seen the incorrect scaling behaviour when running in Ableton Live 10 with DPI awareness enabled and I’ll push a fix shortly.
Hmm, that does look right, but we’re still seeing the broken behavior on latest dev.
Our PluginEditor is just an empty window. We add our real editor Component to the window and resize it when the window is resized. We use an AffineTransform to rescale the component. Here is what we are doing:
const float newScale = float(getWidth()) / editorComponent->getPluginMainWidth();
if(newScale > 0)
“getPluginMainWidth()” is the initial 100% scale width of the component, set only once during the constructor and never changed. We send the interface scale to our processor so that it maintains size when the editor is closed.
Can you reproduce it with a minimal example plug-in?
Still seeing the same problem as before @ed95, with the exact example you’re using in the image. Do you have just one monitor connected to your PC?
EDIT: Just checked with only one monitor plugged in. Issue remains.
@trickyflemming do you see the issue with the PIP attached in the initial post?
@Clarke I’m afraid that I’m still not seeing this, running Cubase 10.0.15 on Windows 10.0.17134. The main display is 3200x1800 at 150% scale and an additional display is connected above this with 1920x1080 resolution at 100% scale.
Alright @ed95, thanks for trying. You can’t do anything about it if you can’t reproduce it there. Really not sure what’s going on. I’m running that same build of Windows and version of Cubase. My main display is 3840x2160, which I think is the same aspect ratio as yours. I’ll be doing more investigation myself at some point, so I’ll post any relevant findings here.
Do you use different gpus maybe?
Nvidia / AMD / Intel?
GPU driver versions?
Using an Nvidia Quadro P400 here, with latest driver version 419.17.