The line drawing width may also have to be adjusted in several places, for example the parameter editor and instrument editor. Maybe we could switch those to use GDI+ (it's implicitely requried by MFC in VS2010+ and comes pre-installed on XP and newer anyway) and have anti-aliased lines as a free bonus.

Starting from Windows 10 1607, there is SetThreadDpiAwarenessContext which we could use to selectively scale some plugin UIs but not others (probably not trivial to implement, though). When OpenMPT is not set to be DPI-aware, we should also consider using SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED) as it will essentially cause fonts to be no longer blurry even when scaled up. There are a couple of remaining UI glitches (some random pixels at the top of pattern and instrument editor, and maybe more) that currently prevent us from using it, and then there is of course also all those plugins that will potentially also look broken for the same reasons.

r22122 brings some more huge improvements for mixed-DPI and high-DPI setups: In particular we were claiming to be per-monitor DPI-aware but were not querying the DPI settings for the correct monitor / window. MFC's resizable dialog is also broken on mixed-DPI setups (or simply when changing the DPI of a single screen while the dialog is open). This has been rewritten as well.

All in all, enabling DPI-aware mode by default could be a good idea by now. I think the only thing really missing is automatically upscaling the default pattern font when a high-DPI device is detected. For custom pattern fonts, we do this automaticalyl.

r22134 enables dynamic scaling for the built-in pattern font.

I'll do a bit more testing with a proper 4K screen and then see if DPI awareness can be enabled by default.

Remaining oddities on high-DPI setups:

• Maximized MDI child windows show part of their (normally hidden) title bar. Maybe a DPI-unaware pixel calculation somewhere in MFC. Not a showstopper if it cannot be fixed.
• First item of `CCheckListBox´ overlaps with the rest of the list. Resolves itself after scrolling. Maybe another DPI-unaware calculation in MFC's implementation. Fixed in r22146

Maximized MDI child windows show part of their (normally hidden) title bar. Maybe a DPI-unaware pixel calculation somewhere in MFC. Not a showstopper if it cannot be fixed.

This also happens in pure WinAPI MDI implementations. Appears to only be an issue on mixed-DPI setups, a single high-DPI screen should not have the same problem.

Edit: https://stackoverflow.com/questions/67304083/problems-with-per-monitor-dpi-aware-mfc-mdi-app