wgc-capture.exe is DPI-unaware, and its monitor lookup silently depends on it

[EtienneLescot]

5efe5e62 opted cursor-sampler.exe into per-monitor-v2 DPI awareness. wgc-capture.exe — the recorder itself — never got the same treatment, and its monitor lookup quietly depends on staying unaware.

Where

findMonitorForCapture (electron/native/wgc-capture/src/monitor_utils.cpp) picks the capture target by matching the bounds it was handed against the rects from EnumDisplayMonitors:

if (rectMatchesBounds(candidate.rect, *bounds)) { return candidate.monitor; }

Those bounds come from sourceDisplay?.bounds and are serialized as displayX/Y/W/H (electron/ipc/handlers.ts:2335). Electron's Display.bounds is in DIPs. The enumerated rects, in a DPI-unaware process, are virtualized — divided by the primary display's scale factor, whatever monitor they actually describe.

Why it works today, and where it stops

Single monitor at any scale: virtualized == DIP, so the two sides agree by accident and the exact match hits.

Mixed-DPI multi-monitor: Electron's DIP rect for each display uses that display's scale, while virtualization uses the primary's for all of them. The two spaces diverge on any non-primary display whose scale differs, rectMatchesBounds misses, and the lookup falls through to the overlap heuristic — which can land on the wrong monitor, or on the primary via MONITOR_DEFAULTTOPRIMARY.

Why it's a paired change, not a one-liner

Adding SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2) to main.cpp on its own flips the enumerated rects to physical while displayX/Y/W/H stay DIPs — that breaks the single-monitor scaled case that currently works. The awareness call has to land together with screen.dipToScreenRect on the TS side (the same conversion windowsNativeRecordingSession.ts:240 already does for the cursor payload), so both sides of the match move to physical at once.

#110 proposed the awareness half (a shared dpi_awareness.h plus the call in main.cpp). That PR is closed as superseded, but this piece of it was never re-landed — hence this issue.

Repro

Needs a mixed-DPI multi-monitor Windows box; not reproducible on a single 100%-scale display, which is what the dev machine is. Same hardware gap as #252.

[EtienneLescot]

Verified, and there is a sharper piece of evidence than the reasoning: the TypeScript layer already applies the conversion on one path and not the other, in the same recording session.

Cursor path, windowsNativeRecordingSession.ts:236-240 — converted, with a comment saying why:

// coordinates via `dipToScreenRect`, which correctly handles the virtual-screen
const physicalBounds = payload.bounds != null ? bounds : screen.dipToScreenRect(null, bounds);

Capture path, handlers.ts:2335 — raw DIPs:

displayX: bounds.x,
displayY: bounds.y,
displayW: bounds.width,
displayH: bounds.height,

So one payload describing the display is physical and the other is virtualized, and the helpers match: cursor-sampler.cpp:419 calls SetProcessDpiAwarenessContext(PER_MONITOR_AWARE_V2), and wgc-capture declares nothing anywhere. The two binaries in the same directory disagree about which coordinate space they live in, and the one doing the recording is the unaware one.

That also settles the "paired change" point beyond argument: the conversion the fix needs is already written and already used a few files away, so landing it at handlers.ts:2335 together with the awareness call is a symmetry restoration rather than a new mechanism.

One thing worth adding to the failure description

The fallback is quieter than "lands on the wrong monitor". findMonitorForCapture tries the exact match, then an overlap heuristic, then MONITOR_DEFAULTTOPRIMARY. On a mixed-DPI setup the overlap heuristic will usually still pick correctly, because the rects overlap heavily even when they disagree. So this is not a clean break: it works, works, works, then silently records the wrong screen on some particular arrangement of scales and positions. That is worse to diagnose from a bug report than a hard failure, and it is worth saying in the issue so nobody dismisses it as theoretical because their two-monitor setup happened to work.

On reproduction

Unlike #252, this one does not need a reproduction to fix. Comparing values from two different coordinate spaces is a defect visible by reading, and the asymmetry above is the proof. Mixed-DPI hardware is only needed to verify the fix, not to justify it.

[github-actions]

Fixed by #351 and merged into main.

This change is assigned to the Next Release release milestone and is not necessarily available in the latest downloadable desktop release yet. It is currently marked as status: pending release until a packaged release containing it is published.