Quote:
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.
Quote:
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 `SetProcessDpiAware
ness()` 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.