Cubase 10 HiDPI, Windows and OpenGL

Nvidia here as well: Nvidia GTX 960

In this other thread (Scaling issues on Windows - #7 by flyingisfun1217), @FlyingIsFun1217 found out that the version of Windows 10 can make a difference:

So it would appear that this isn’t the fault of Juce, but rather of something in the way the old Windows builds handle scaling.

Maybe that could explain why @ed95 cannot reproduce @Clarke’s issue.

Thanks @McMartin, though I’m using Windows 10.0.17134, the same build as @ed95 said he was running above.

OK, shot in the dark but from reading this SO thread it might be due to the way that different drivers expect the glViewport to be set up.

Can you try replacing line 284 of juce_OpenGLContext.cpp with the following:

auto newScale = 1.0;

and see if that helps at all?

That ends up with this:

If you look carefully, the text (what you can see of it) appears to have scaling artifacts - as if it has been scaled down from a larger image.

I’m running in a similar issue. Our flagship product is exhibiting this behavior and our 4k Windows users are starting to send in requests to get this fixed.

I’m able to reproduce what I think is the issue with the AudioPluginDemo:
Visual Studio 2017, Windows 10, Cubase 10.0.15

  1. Set Windows Display Settings scaling to 125% (or anything larger than 100%)
  2. Enable HDPi in Cubase
  3. Download/clone JUCE repo develop branch
  4. Make sure to set global paths to that repo
  5. Open AudioPluginDemo, save and build
  6. Open in Cubase. It looks fine! Resizing works well too:
    WithoutOpenGL
  7. Now in the editor class, add an OpenGLContext and attach it
  8. Open in Cubase and this is what I get:
    WithOpenGL

Our product looks very similar, with the top portion push downward and mouse clicks not triggering in the correct areas, etc…

@ed95 are you able to reproduce this? I’m happy to offer help in any way. Thanks!

No, as I said above everything looks normal when using the OpenGL renderer with a hiDPI plug-in for me.

Is this only happening in Cubase 10? Have you tried any other DAWs? What GPU do you have on the machine that this is happening on? As mentioned above it could be a driver issue, I have an Intel HD 5500 on my machine but it seems like the issues are happening with Nvidia cards.

I checked on my MBP (Intel Iris Graphics 540) and it works! My main dev machine has an Nvidia GeForce GTX 1050 Ti, so it does look like the issue only happens on certain cards. I’ll try to see if I can get info on our user’s card.

EDIT: I totally goofed, I forgot to add the OpenGLContext when I tested on my MBP. When I add the context and attach it the issue occurs again. Also, the graphics card our user has is a non-Nvidia.

I tested in Studio One 4 and it seems to work well there with HDPi mode turned on scaling turned up.

I’ve done some more testing with this.

Regarding graphics cards, this occurs on 3 different machines with these graphics cards (all running latest Windows 10)
Intel Iris Graphics 540
Nvidia GeForce GTX 1050 Ti
2048MB ATI Matrox C420 LP

The scaling works fine in the following hosts (making sure to have HDPi enabled when the option is available):
• Studio One 4
• Ableton Live 10
• Reaper

In the hosts I tested it’s these hosts where the issue crops up:
• Cubase 10
• Nuendo 8
• Wavelab 9
In Cubase and Wavelab the issue manifests as rendering with everything rendering out of place (like in the previous screenshot I posted) with no way to resize. In Nuendo the plugins load the same way initially, but then you can drag the resizer corner and then they look/control fine!

So it looks like there’s something Steinberg related to the problem. Can any other JUCEers confirm this? :stuck_out_tongue:

@ed95 I’ve just tried testing this again with the latest develop branch changes. This time I used VS2019 with the latest Windows 10 SDK. The issue still persists on the three graphics cards listed above.

Any chance you could test this on a couple other machines? It doesn’t take more than a few minutes.

I also have some developer contacts at Steinberg if you’d like me to put you all in touch.

Thanks!

I was able to test this out on a different Windows machine last week and could reproduce the issue. I’ve got a fix and it’ll be on develop soon after it’s passed our CI.

1 Like
4 Likes

@ed95, builds are now failing when only building VST3 due to a missing definition of juce_shouldDoubleScaleNativeWindow.

Ah, I’ll get that fixed. Thanks for the heads up.

2 Likes
3 Likes

No longer seeing the issue here in Cubase 10 using the example PIP. Thanks @ed95!

2 Likes

Just tested on my machines with our product and it looks great! Thanks so much @ed95!

One more thing @ed95. Need a nullptr check on the getProcessDPIAwareness function pointer in the function below, otherwise it crashes on Windows 7.

4 Likes

Replying here even though the issue I’m observing is not opengl related.
Specs: Win10 1903, Cubase 10.0.30 and 10.0.40, JUCE 5.4.3 and 5.4.4.
This affects VST3 plugins.
I’m observing broken scaling in a very particular case:

  1. Configure a windows 10 system with two displays, with the primary display having a scale factor of 100%, the secondary display a scale factor of 200%
  2. Use Cubase 10.0.30 or 10.0.40 with high dpi enabled, maximize it on the primary screen.
  3. Create an empty project with a plugin instance
  4. Move the plugin window to the secondary screen (the one with 200% scale)
  5. Close the plugin ui (cubase will remember the window position)
  6. Open the plugin ui
  7. Observe that the window is too small and the Plugin UI is getting truncated. Plugin-internal scaling is correct, the window bounds are not.

This is observable with an empty projucer template plugin project.

Some additional observations:

The bug works the other way round too: When opening the plugin on the secondary screen, the window bounds are too big, following a scale factor of 200%, while the contents are being scaled correctly (100%). In this case, moving the plugin back and forth between two screens temporarily fixes it.

Code/Debugging: On plugin UI open, setContentScaleFactor is called 3 times:

  1. with factor 1
  2. with factor 2
  3. with factor 1 again

It is worth noting that plugins by other vendors are being affected too.

Now, to me this looks like Cubase is reporting wrong factors to the Plugin, but I’m not 100% certain. It took me some time to find a particular setup for which this becomes reproducable (see steps above). Some (few) clients reported the issue and I have no idea how to easily fix this.

Any insight or confirmation would be helpful, thanks!