Thanks there is a small light at the end of this tunnel…
HOWEVER - I know engineers may say this is not quick, but as a CEO of engineers and a former programmer myself, this fix for HiDPI support of plugin windows is only a few dozen lines of code and a couple monitors for one coder. MAYBE another pair of eyes to help test all edge cases. I guarantee I could fix this issue in 3 days MAXIMUM.
Taking 2+ years to fix this for Nuendo/Cubase with potentially thousands of users complaining and ~10x+ not complaining but experiencing issues is driving everybody crazy. It damages reputation and sales during trial periods considerably.
Look at Windows API docs on DPI:
a simple function process like this is needed:
FUNCTION OnEditVSTInstrument or OnWindowMoved
GET MONITOR DPI (multi monitors)
ADJUST DPI
TEST
protected virtual void OnDpiChanged(DpiScale oldDpi, DpiScale newDpi)
Here is the latest Windows per monitor HIDPI API docs. Most of the HiDPI API for Windows was last modified in 2018.
https://github.com/microsoft/WPF-Samples/blob/master/PerMonitorDPI/readme.md
AND TESTING:
After you have updated your application to become per-monitor DPI aware, it is important to validate your application properly responds to DPI changes in a mixed-DPI environment. Some specifics to test include:
Moving application windows back and forth between displays of different DPI values
Starting your application on displays of different DPI values
Changing the scale factor for your monitor while the application is running
Changing the display that you use as the primary display, signing out of Windows, then re-testing your application after signing back in. This is particularly useful in finding code that uses hard-coded sizes/dimensions.
THAT’S IT!