Support per-monitor DPI

[reupen]

Since Windows 10 1607, per-monitor DPI awareness can be set per (top-level) window. Therefore, it's now possible to achieve some level of per-monitor DPI support (as the entire process doesn't have to be running in the same mode).

(More details: https://docs.microsoft.com/en-gb/windows/win32/hidpi/high-dpi-improvements-for-desktop-applications)

Third-party panel compatibility is still likely to be problematic as they would all need to implement per-monitor DPI support themselves.

Therefore, a starting point would be to add support to all dialogue boxes directly created by Columns UI (as these are self-contained and don't involve other third-party components or libraries).

Tasks

Add support to various dialogues/pseudo-dialogues:

• [x] Add and edit group
• [ ] Buttons options
• [x] Buttons options command picker
• [ ] Custom info boxes e.g. Filter field help in preferences
• [x] Export FCL
• [x] Import FCL
• [x] Import FCL errors
• [x] Item details options
• [ ] Item properties options
• [x] Spectrum analyser options
• [x] New playlist, rename playlist, new layout preset and rename layout preset
• [x] Quick set-up

Add support to UI components:

• [ ] Custom list view control
• [ ] Custom track bar control
• [ ] Main layout area
• [ ] Main window
• [ ] Toolbars
• [ ] Status bar
• [ ] Status pane

Add support to built-in panels:

• [ ] Artwork view
• [ ] Buttons
• [ ] Drop-down toolbars (playback order etc.)
• [ ] Filter
• [ ] Filter search
• [ ] Horizontal and vertical splitters
• [ ] Item details
• [ ] Menu bar
• [ ] Seek bar
• [ ] Spectrum analyser
• [ ] Playlist switcher
• [ ] Playlist tabs
• [ ] Playlist view
• [ ] Tab stack
• [ ] Volume bar

Panel API:

• [x] Add support for custom DPIs to cui::fonts::manager
• [ ] Add utilities to Columns UI SDK
• [ ] Write documentation

[reupen]

Some additional points from further investigating this.

• From the article linked above:

  When the window procedure for a window is called, the thread is automatically switched to the DPI awareness context that was in use when the window was created.

  This is important as it means per-monitor DPI aware window procedures need to be careful to reset the context when calling external code that isn't expecting it (e.g. foobar2000 APIs or internal code that does stuff with other windows). This adds complexity in a lot of places.

• There were further changes in Windows 10 1803: https://docs.microsoft.com/en-gb/windows/win32/api/winuser/nf-winuser-setthreaddpihostingbehavior

  It is, seemingly, now possible to have a per monitor DPI-aware top-level window with child windows that aren't per-monitor DPI aware. This should help solve the problem with non-per-monitor DPI aware panel components.

[reupen]

Unfortunately, a few problems were encountered when actually implementing this. The most notable one was that the thread DPI awareness context leaks out into timer procedures created by SetTimer with a NULL hwnd when you e.g. right-click on the title bar of a per-thread DPI aware window (as the displayed menu blocks and has its own message loop). This can cause the code in such timer procedures to misbehave if they aren't expecting this.

Therefore, this work is on hold for now and the small merged part will be reverted.

Ideally, Windows would associate a DPI awareness context with such timers, just as it does for windows. I'm not sure what the best way to give feedback to Microsoft about that as a developer is.

[TheQwertiest]

I'm not sure what the best way to give feedback to Microsoft about that as a developer is.

AFAIK, there are only two ways to reach MS devs:

• https://developercommunity.visualstudio.com : not directly related, but has the greatest likelihood of receiving an answer and they might even forward your report to the appropriate teams.
• Win10 feedback hub : a proper way, but it feels like a placebo black-hole box, since you'll never receive an answer...

[reupen]

Thanks. I see there's a 'Developer platform' section in the Feedback Hub nowadays, so that might be worth a go. (And yep, I have seen the VS Developer Feedback work before as well...)