We had customer reports about GUI scaling issues with our plugins on Windows 10 in WaveLab 11.2 (The system DPI scaling factor is set to 150%).
Although WaveLab seems to be a “DPI-unaware” application and accordingly the scaling factors reported by HiDPISupport::getDPIForWindow() / 96.0 or passed to setContentScaleFactor() are both 1.0. Nonetheless, the container windows size is off by a factor of 2.0.
It works fine in other hosts, but we considered something is wrong with our implementation, so we checked the AGain example that comes with the SDK. And, lo and behold, it exhibits the same behavior (see screenshot below).
This might well be a bug in WaveLab itself, but the strange thing is that other vendors’ plugins do not suffer from this bug.
Any ideas? Has anyone else run into the same issue?
With the following option ON, for the VST3 AGain plugin, the display is correct on my three connected screens (100% scaling, 150% and 200%). I am using the latest Windows 11 though, and I would recommend this.
I can confirm this issue with VST3 AGain – and also built-in plugins like MasterRig and SuperVision – in WaveLab 11.2 on Windows 10 when screen resolution is 3840 or higher.
I have checked on a second computer, with Windows 11 latest, with a single screen with a resolution of 3840 x 2160, and the result is normal. I even tried various scaling 100% / 125% / 150% (the recommended one for my screen) 175% and 200%. All are ok.
I have checked on a third (old) computer, this time with Windows 10 version 22H2 (OS Build 19045.2486), with a single screen with a resolution of 3840 x 2160, and the result is normal exactly as above. I also tried all scaling coefficients. All are ok.
My conclusion is that either you are using an old Windows 10 version , or an old graphic card driver. I don’t see any other possibility.
Make sure you use the latest WaveLab, that is 11.2, and erase all WaveLab preferences to make sure you start from good defaults. \AppData\Roaming\Steinberg\WaveLab Pro 11\
I have no more clue to help since I can’t reproduce on my 3 different machines.
New WaveLab 11.2 installed from executable here on machine with no prior WaveLab installation.
I guess we’re imagining the screenshots?
Strange is…
the scaling factors reported by HiDPISupport::getDPIForWindow() / 96.0 or passed to setContentScaleFactor() are both 1.0. Nonetheless, the container windows size is off by a factor of 2.0.
The bug maybe in Windows after all, or their clumsy implementation of HiDPI.
Have you checked that you don’t have overwritten the HiDPI settings in the Windows control panel for WaveLab?
I’m a user, not a dev (but I am programmer ), but after having encountered this with plugins from TDR, Softube and Leapwing, I thought I’d chime in. On a Win11, 3840x2160, scaled to 125%, I get GUI clipping (TDR) and “ballooning” (Softube) with WL11.2 set to HiDPI. I just found that if I override the app defaults (Compatibility → Change high DPI settings → Override → System) the problem disappears, BUT, then all WL text is blurry, ie not really a solution. So, is this a plugin (framework), WL or Windows problem? I know that Leapwing solved it themselves, can they be contacted for a generic fix?
), but after having encountered this with plugins from TDR, Softube and Leapwing, I thought I’d chime in. On a Win11, 3840x2160, scaled to 125%, I get GUI clipping (TDR) and “ballooning” (Softube) with WL11.2 set to HiDPI. I just found that if I override the app defaults (Compatibility → Change high DPI settings → Override → System) the problem disappears, BUT, then all WL text is blurry, ie not really a solution. So, is this a plugin (framework), WL or Windows problem? I know that Leapwing solved it themselves, can they be contacted for a generic fix?