Hi. The desktop scaling factor editor.openGLContext.getRenderingScale() now always returns 1.0 instead of the Windows scaling factor.
Going back to version 7.0.8 fixes this for me.
edited
Going back to 7.0.8 fixes the scale factor on Windows, but I haven’t tested MacOS yet.
I can’t reproduce that. My stand-alone app uses an OpenGL context for one of it’s pages and it renders at the correct scale.
Just to avoid confusion: I’m creating my own triangle-lists, shaders, textures, etc. so it’s not JUCE compensating somewhere.
This is on a 3840x2160 display with the scale factor set to 200% on Windows 11.
Interesting, thanks for testing. I create a plug-in wide GL panel and set viewports for each part that has OpenGL display on it, so I can display many panels with just one context. The panels are now way off positions and scales.
I use getRenderingScale() and it’s always returning 1.0 on Windows, with 7.09. What does your getRenderingScale() return with a scale of 150%?
I’m on Windows 10, I have no idea if that makes a difference.
I’ve set a breakpoint, and it reports 2.0. Which I then use to multiply my rectangle coords with to scale them correctly.
A scale of 2 with 150%? Huh! It’s suppose to be 1.5, isn’t it?
The problem gets worse for me, as Cubase 10 reports 2.0 on boot up, when it’s supposed to be 1.5 for me, so the whole plug-in is now far too large for it’s window. I have to re-size it by dragging the corner to fix the error. Very odd behaviour.
I’m going back to 7.0.5 tomorrow, and resetting everything to how it was yesterday. Waste of a day.
My desktop scale is 200%, not 150%.
1 Like
OK, it’s always returning 1.0 for me, this is on FL Studio, Cubase 10, Live 10, and Reaper.
This is on Windows 10, I presume the Juce team still tests on 10?
Perhaps I’m calling the wrong one? I’m calling:
editor.openGLContext.getRenderingScale();
I’m using the context in the editor. It’s the only context I have.
What happens when you try the VST2 version? AFAIK the VST3 version gets told by the host which scale to use, and I think there’s a bug in the spec that only allows for integer scale, so 1.5 won’t work. But 2.0 should.
Also, please keep in mind that I’ve been using it in a stand-alone app, not any plugin context whatsoever. It’s a juce::JUCEApplication, not a plugin-editor.
Could be related to that, but could be something different too.
(I didn’t check the purposed fix yet for m my issue, because I didn’t have the time)
Maybe you try a git bisect to find the reason
1 Like
Yeah, I saw that post yesterday, I’ll do that, thanks.
Thank you for reporting, I can see this regression as well. We’ll try to address this as soon as possible.
1 Like
Thanks @attila. I can confirm that going back to before the scale changes fixes the problem for me:
git reset --hard 17c9de053f04a6f8beb83fb1a8e2c4b25fd33ae5
After that, the host now provides the correct scaling value.
Hmm, this commit is the one before the breaking change:
For anyone else with windows scaling problems…
git reset --hard 17d81f9c1d2d78a9b21f59a72d1f7cb7e34648ea
Sorry to bother the Juce team, but is there any way we can fix this breaking change in Windows?
A plug-in it needs to use the host’s actually DPI settings, instead of just returning 1.0f.
Thanks
Dave H
A fix has been released on develop
1 Like
@attila Marvelous, thanks. Why only Develop this time?
Changes initially land on develop as they are ready. Point releases are released periodically, once larger changes have been available on develop for a while to be tested by the community.
There is a point release on the horizon, but it could be a week or two before it’s out.
I really like that protocol; but that’s not what happened here in this case - The breaking change was made to ‘master,’ and apparently went by untested for months. Anyway, thanks again for the future fix.