Windows screen geometry details: DWM frame bounds, row-centre rounding, DPI mode table, minimised-window clamp

Windows screen geometry details

Setup for every number below: a 2560x1440 monitor at 150% scaling as primary, and a 1920x1080 monitor at 100% positioned at x=2560. Windows 11, PowerShell, UI Automation client.

What each DPI awareness mode reports

| Awareness mode | Monitor 1 | Monitor 2 | Virtual screen | Usable? | |---|---|---|---|---| | Unaware (PowerShell default) | 1707x960 at (0,0) | 1920x1080 at (2560,0) | 4480x1080 | No | | SetProcessDPIAware() (system aware) | 2560x1440 at (0,0) | 2880x1620 at (3840,0) | 6720x1620 | No | | SetProcessDpiAwarenessContext(-4) (per-monitor v2) | 2560x1440 at (0,0) | 1920x1080 at (2560,0) | 4480x1440 | Yes |

The unaware row is internally inconsistent: monitor 1's size is scaled (2560 / 1.5 = 1707) while monitor 2's origin is physical (2560). No single scale factor recovers it. The system-aware row inflates the 100% monitor by 1.5x, so a click aimed at monitor 2 lands about 1280 px off. The mode must be set before System.Windows.Forms or UIAutomationClient load, because values cached at load are not corrected afterwards. A cheap self-check: the sum of per-monitor widths must equal the virtual-screen width, and a captured bitmap must match the virtual-screen dimensions.

DWM frame bounds versus the Win32 rect

A top-level window's Win32 rect (GetWindowRect) and its DWM extended frame bounds (DwmGetWindowAttribute with DWMWA_EXTENDED_FRAME_BOUNDS) differ by about 9 px, because of an invisible resize border. Cropping a screenshot with the Win32 rect gives an image offset from the geometry that UI Automation reports for the visible content. Using the DWM bounds for the crop removed the offset.

Row-centre rounding

On a list with uniform 43 px row pitch, computing each row centre as cy = y + h/2 from each row's own rect alternated between 44 and 42 because of integer rounding. A check for "uniform pitch" that compares centres fails on that input. Detecting the pitch on the top edge (y) gives a constant 43.

SetCursorPos clamps instead of failing

SetCursorPos returns success for points outside the virtual screen and moves the cursor to the nearest reachable point. A minimised Teams window still produced a UI Automation tree: 608 descendants, 591 with control patterns, all reporting IsEnabled=True and IsOffscreen=False, at rectangles near (-32000,-32000). One element at (-31828,-31964) was clamped by SetCursorPos to (2560,0), which is a different live window, and the click landed there with no error. Another minimised Teams element reported an in-range point (279,132) that belonged to a different application.

Checks that address this: look for -32000 origins or a tiny size in the window rect, restore and activate before acting, and read the position back with GetCursorPos after SetCursorPos to detect clamping.

Dead zone in the virtual rectangle

With monitors of different heights, the virtual rectangle covers area no monitor occupies. On this layout it was x[2560,4480) by y[1080,1440), 10.7% of the area of a full-desktop capture. A bounding-box test passes for points in it. Validating against the union of individual monitor rectangles rejects them.

Not verified

Behaviour on other scale factors (125%, 175%, 200%) and on layouts with a monitor to the left of or above the primary was not measured here. The origin can be negative in those layouts, which affects any mapping from an image pixel back to a screen point.