High-DPI: pre-8.1 Windows (e.g. 7) are capable too

[MT_]

HiDPI (High-DPI) features in Reaper 5.32+ are apparently currently available in Windows 8.1+ only and not available in previous versions like Windows 7 with its 50% market share.

I suppose this is just a temporary limitation due to the experimental nature of HiDPI-related work in Reaper for now.

But, just in case, please note that previous versions of Windows (Vista+) do support setting DPI awareness too, just with another WinAPI function: `SetProcessDPIAware()` instead of Win8.1+-only `SetProcessDpiAwareness()` you’re obviously using currently.

The reason why `SetProcessDpiAwareness()` has been invented in addition to existing `SetProcessDPIAware()` in the first place was just that before Window 8.1, there was only one global (system) boolean DPI-awareness mode (on/off), while Windows 8.1 has introduced per-monitor DPI awareness, so a new non-boolean-oriented function has naturally become needed.

Unless you’ve really implemented per-monitor DPI-awareness support in Reaper, to support HiDPI in all popular Windows versions including Windows 7, just use the `SetProcessDPIAware()` function alone. Once you’ve implemented per-monitor DPI awareness, use both functions conditionally: `SetProcessDpiAwareness()` if it’s available (Windows 8.1+) and `SetProcessDPIAware()` otherwise (Windows Vista through 8.1). That’s all.

Nice to see movement toward HiDPI support in Reaper in general, by the way.

Thanks for your attention.

[MT_]

MSDN documentation for both WinAPI functions for your convenience:

• SetProcessDPIAware() (Windows Vista+)
• SetProcessDpiAwareness() (Windows 8.1+)

[Justin]

Per the documentation:

Note SetProcessDPIAware is subject to a possible race condition if a DLL caches dpi settings during initialization. For this reason, it is recommended that dpi-aware be set through the application (.exe) manifest rather than by calling SetProcessDPIAware.

For this reason, I'd recommend any Windows 7 users who want to experiment with enabling HiDPI support create a manifest file for reaper.exe, and use that (one does not need to modify reaper.exe, simply installing the manifest file with reaper.exe is sufficient).

[MT_]

Originally Posted by Justin

One does not need to modify reaper.exe, simply installing the manifest file with reaper.exe is sufficient.

Justin, according to my experience, external (as a separate file) manifest does not work if the executable already contains its own manifest built-in (and Reaper already has such embedded manifest, so Windows just ignores the external manifest file). That’s why I’ve been forced to edit/recompile reaper.exe itself with Resource Hacker when testing my proposed “VST host as a separate executable” solution for VST-plugin HiDPI compatibility.

But actually, I’m concerned more about OS compatibility of the final stable implementation than just about being able to test the feature right now in its experimental state (it’s OK for me just to use a virtual machine for testing).

Once Reaper’s HiDPI support is stabilized, it’s better to declare DPI awareness via manifest instead of calling a WinAPI function — that’s what Microsoft recommends. But if not, it’s important to be sure there will be no unreasonable limitations like Win8.1+ we currently have — that’s the main point of this topic. Thanks.

Originally Posted by Justin

SetProcessDPIAware is subject to a possible race condition if a DLL caches dpi settings during initialization.

As a side note, I suppose the same applies to the `SetProcessDpiAwareness()` function currently used in Reaper. But actually, the possibility of the race condition is not critical (fwiw, I did never encounter such issue in practice): when a user needs HiDPI mode (and it is actually implemented in the application), he just enables it once without flipping the option back and forth multiple times during the same Windows session. Studio One 3+ successfully uses the WinAPI-function approach for enabling HiDPI depending on settings, but indeed, it’s better just to use manifest.