Windows Hi-DPI support

[p0nce]

A complicated issue for sure.

Thing are blurry in non-100% DPI on Windows.

More or less separate from #278. DPI awareness for macOS, Linux and Win32 can be implemented separately.

Lost of useful info here: https://www.enlyze.com/blog/writing-win32-apps-like-its-2020/part-3/

• [x] Adjust size with AdjustWindowRectExForDpi if available => no need it seems
• [x] handle WM_SIZE => no need
• [x] handle WM_DPICHANGED for awareness v2 => OK, but doesn't get right DPI in Bitwig, need to force thread-awareness if possible. (EDIT: was a bad idea)
• [x] handle WM_GETDPISCALEDSIZE and test with Per Monitor v2 awareness host => no need it seems
• [x] scale mouse movement by DPI? => don't think it's useful.
• [ ] IWindowListener should have new interface call: getSizeOfWindow(float dpi, out int width, out int height) The default size is returned with DPI 100% aka 1.0f. The window constructor is not given a size in pixels anymore.
• [x] Ability to create the window in a Hi-DPI context with save/restore of the thread DPI-awareness around the CreateWindow => this doesn't seem to work that well?

[p0nce]

Testing the following hosts:

• [x] FLStudio => Per Monitor v1
• [x] Live => unaware
• [x] REAPER => Per Monitor v1
• [x] Orion => unaware
• [x] Waveform => Per Monitor v2
• [x] Studio One => Per Monitor v1
• [x] Bitwig =>Per Monitor v2

[p0nce]

Interesting: the window get to know the DPI, but when DPI-aware is free to choose its own size. So there isn't necessarily a need for resizer, when multiple sizes are provided. Will need a declarative flexible way to declare which size interface size are available.

[p0nce]

If resizer is used, it mustn't be on the windowing side, but in the GUIGraphics side. Only the window need to know a "DPI" apparently, but it resize the client area passed to GUIGraphics, who must deal with that size however it wants.

[p0nce]

Apparently we can have Hi-DPI in hosts that don't support it somehow? https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-improvements-for-desktop-applications

[p0nce]

Bitwig wrapper (Bitwig is itself Hi-DPI awareness context v2) doesn't have plugin with DPI awareness, as it seems.

[p0nce]

Waveform get the right DPI in WM_DPICHANGED, however the window is not resized to be larger.

[p0nce]

Test DPI_HOSTING_BEHAVIOR and DPI_AWARENESS_CONTEXT before window creation, and whether the window is stretched in the end :

• [x] FLStudio => DPI_HOSTING_BEHAVIOR_DEFAULT and DPI_AWARENESS_PER_MONITOR_AWARE, Context change OK but not all necessary, is correct scale at instantiation, doesn't receive WM_DPICHANGED (like REAPER), size of window increasing with each open/close :(. In FL the user can force context to be DPI_AWARENESS_SYSTEM_AWARE instead.
• [x] REAPER => DPI_HOSTING_BEHAVIOR_DEFAULT and DPI_AWARENESS_PER_MONITOR_AWARE, change OK but not all necessary, is correct scale at instantiation, doesn't receive WM_DPICHANGED
• [x] Live with DPI-aware right-click => DPI_HOSTING_BEHAVIOR_DEFAULT and DPI_AWARENESS_PER_MONITOR_AWARE. Change OK but unnecessary. Is right size, but doesn't receive WM_DPICHANGED
• [x] Live by default => DPI_HOSTING_BEHAVIOR_DEFAULT and DPI_AWARENESS_UNAWARE. Context change OK. Stretched.
• [x] Orion => DPI_HOSTING_BEHAVIOR_DEFAULT and DPI_AWARENESS_UNAWARE, Context change OK, is stretched.
• [x] Waveform => DPI_HOSTING_BEHAVIOR_DEFAULT and DPI_AWARENESS_PER_MONITOR_AWARE or DPI_AWARENESS_UNAWARE (default is unaware, like Live and Bitwig. Crash on DPI change.
• [x] Studio One => DPI_HOSTING_BEHAVIOR_DEFAULT and DPI_AWARENESS_PER_MONITOR_AWARE, context change OK and unnecessary, right size, doesn't receive WM_DPICHANGED.
• [x] Bitwig => DPI_HOSTING_BEHAVIOR_DEFAULT and DPI_AWARENESS_UNAWARE. Context change OK. Stretched.

Conclusion: WM_DPICHANGED never received when changing DPI of a single monitor. Strange.

[p0nce]

IPlug compares the Windows DPI to the monitor DPI to detect DPI change, which could be alright?

[p0nce]

One real problem in Hi-DPI is the shit tier upsampling done by Windows when DPI_AWARENESS_UNAWARE. There is a better GDI upsampling available in Windows 10, hopefully it becomes the default at one point?

[p0nce]

• Trying to force a HiDPI context is not such a good idea. Popular hosts have seemingly a whitelist, so we should behave correctly with or without DPI being enabled in those hosts (FLStudio, Live, Waveform can switch on/off Hi-DPI before we brute-force their decision). None of the hosts in the wild were using that "mixed" behavior Hi-DPI thing apparently.
• WM_DPICHANGED isn't sent for some reason, so maybe we could just read DPI of current screen of window, and adapt in that case.
• this item is less useful than resizing

[p0nce]

Blocked until we get more experience getting size changes from host or windowing. For now, increasing sizes will have a positive effect regardless, and most positive in advanced hosts that support Hi-DPI.

[p0nce]

Either we can find a way to create an always-DPI-aware window for plugin view, or it is a futile issue. Popular host open plugin in either hiDPI or not depending on options they remember.

[p0nce]

QA with Hi-DPI screen says it is sharp on Windows (and with the same screen, report problems on macOS) which means the host is Hi-DPI and instantiate DPI-aware plugins where we don't have anything to do. So... much less important than Hi-DPI on macOS.

[p0nce]

VST3 has a way to get the DPI CLAP pushes that