Skip to content

DPI Awareness #39

@adipose

Description

@adipose

Please see DPI aware dialog implemented in mpc-hc, based on resizablelib.

clsid2/mpc-hc#3669

I would like to see this considered for inclusion in resizablelib. As it currently behaves, it is a fully derived class from CResizableDialog, which means it is nearly harmless to include as-is (you'd need to add some small dependencies from DpiHelper, but they are pretty minimal). However, as the expert of the original code, you may spot ways to improve it.

One thing to note is that I had to override/replace OnSize due to inability to access private members of CResizableGrip. I think it may still be the cleanest way to do it, but I had other options when changing CResizableGrip header to be more public.

Code is not yet imported to mpc-hc, but it works well. Here are some use cases to consider:

First, assume there are two monitors with different DPIs (call them 168dpi as default monitor, and 96dpi as secondary).

  1. MPC-HC starts on 168dpi monitor, opens a pop-up dialog, drag to 96dpi screen
  2. MPC-HC starts on 168dpi monitor, opens a pop-up dialog, resizes, drag to 96dpi screen
  3. MPC-HC starts on 96dpi monitor, opens a pop-up dialog, drag to 168dpi screen
  4. MPC-HC starts on 96dpi monitor, opens a pop-up dialog, resizes, drag to 168dpi screen
  5. MPC-HC remembers starting location on 96dpi screen. Double click on 168dpi screen shortcut, opens on 96dpi screen. Do steps 3-4 in this case.
  6. MPC-HC remembers starting location on 168dpi screen. Double click on 96dpi screen shortcut, opens on 168dpi screen. Do steps 1-2 in this case.
  7. MPC-HC starts on 168dpi monitor, drag to 96dpi monitor. Do steps 3-4 in this case.
  8. MPC-HC starts on 96dpi monitor, drag to 168dpi monitor. Do steps 1-2 in this case.
  9. Repeat steps 1-4, but then resize and drag back

Things to validate:

  1. The size of buttons and dialog matches what would happen if the dialog was originally native to the new dpi monitor. Please note that win32 will "guess" at a new size of a dialog and suggest it to you during WM_DPICHANGED. It is seemingly always different from what a new dialog started on that monitor would have been. However, controls should have right fonts and some will be the right size. So we override that behavior.
  2. Gripper must never disappear or become wrongly aligned to the corner.
  3. Anchors must behave as if they were placed on the new DPI originally. i.e., bottom right anchor should remain distant from the bottom right corner by the same DLUs regardless of DPI
  4. Min/max size must translate. Note, I have taken a shortcut to allow min/max to be defined by scale of original dialog rather than hardcoded to pixels (makes no sense in a dpi context).
  5. Saved position needs to work. I haven't tested this yet, but I believe it should be "fine" without considering DPI since it will restore to the monitor with the saved dpi.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions