Will SysGet in v2 be per-monitor dpi aware?

[Bja]

As far as I understand, the SysGet MonitorWorkArea in v1 only uses the scaling of the main display.
Thus if other monitors are using a different scaling, this method will not work for them (will return wrong values).

Will there be introduced new per-monitor DPI / scaling aware functions with V2?


Alternatively (or additionally):
Will there be introduced function for getting the serial number or some other non-changing identifier of the connected monitors?
Or/and getting the raw resolution + scaling for any connected display?

[lexikos]

SysGet doesn't use the scaling of the main display or otherwise have anything to do with DPI awareness. It just calls system functions to retrieve information. Those functions are affected by DPI awareness, although the documentation (for GetMonitorInfo) does not say so. My observation has been that some APIs use the scaling of whichever display the script's last active window was on (if it had any). That is not necessarily the main display, although I do not know if this applies to SysGet.

There is no concrete plan to solve the problems caused by DPI virtualization. However, you can enable per-monitor DPI awareness on Windows 10 with a single line of code. See Sizing GUI-Elements: dpi dpiaware has to be set to "True/PM" to work on Win 8.1 and above. I think that avoiding the coordinate scaling caused by "DPI unawareness" is more important overall than retaining DPI virtualization for GUIs, so I will probably enable per-monitor DPI awareness in the application manifest, despite the loss of automatic scaling for GUIs.


v2 is not about adding new functions or features. I personally have no current plans to add any functions relating to monitors, in any version.

The Monitor sub-commands of SysGet are separate functions in v2. SysGet only handles "system properties" that can be returned by the GetSystemMetrics system function.

[guest3456]

SysGet doesn't use the scaling of the main display or otherwise have anything to do with DPI awareness. It just calls system functions to retrieve information. Those functions are affected by DPI awareness, although the documentation (for GetMonitorInfo) does not say so.

the struct docs say this:

https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-monitorinfo

rcWork

A RECT structure that specifies the work area rectangle of the display monitor, expressed in virtual-screen coordinates

maybe that's what they mean

I think that avoiding the coordinate scaling caused by "DPI unawareness" is more important overall than retaining DPI virtualization for GUIs, so I will probably enable per-monitor DPI awareness in the application manifest, despite the loss of automatic scaling for GUIs.

i think changing the manifest should be sufficient to get windows to return the correct values in respect to the scaling of each individual monitor. the OP in the "true/pm" post observed so too

[lexikos]

What I mean to say is that the documentation does not specify *how* DPI scaling affects the coordinates, or how the scale is determined for a given thread, given that these operations don't relate to a specific window.

i think changing the manifest should be sufficient to get windows to return the correct values in respect to the scaling of each individual monitor.

The API would return the actual unscaled values, regardless of the scaling of each individual monitor. That's the point.

The issue is that it also disables the automatic scaling that occurs when you move a GUI between screens.

[Bja]

Thank you very much for pointing me in the right direction.

Calling originalContext := DllCall("SetThreadDpiAwarenessContext", "ptr", -3, "ptr")
prior to moving the window, and
DllCall("SetThreadDpiAwarenessContext", "ptr", originalContext, "ptr")
after moving the window did indeed solve the problem.

Now I feel foolish for not managing to find that other post during my search.
But I am glad to learn that per monitor DPI awareness isn't actually a problem with AHK.