Fix DPI change handling for additional monitor windows#28
Draft
Fix DPI change handling for additional monitor windows#28
Conversation
Copilot
AI
changed the title
[WIP] File issues for DPI-related code review
Fix DPI change handling for additional monitor windows
Feb 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Additional monitor windows created via
CreateMonitorWindow()don't respond to runtime DPI changes, causing incorrect rendering and hole-punch positioning when users move windows between monitors with different scaling or change system DPI settings.Changes
DpiChangedevent handler to additional monitor windows inCreateMonitorWindow()that updatesctx.DpiScaleX/Yand repositions windowApplyHolePunchEffect()uses current DPI values fromMonitorWindowContextRoot Cause
Main window has
OnDpiChanged()override (lines 585-619) that updates_dpiScaleX/Yand repositions. Additional monitor windows had no equivalent handler, leaving theirctx.DpiScaleX/Yfrozen at creation-time values.Affects multi-monitor setups where monitors have different scaling factors or users change DPI at runtime.
Original prompt
Fantastic. Let's go and file issues for both one and two separately using the GitHub CLI and then assign those to Copilot in the cloud and let it work on them.
[Chronological Review] 1. User initiated a code review via /review command, specifically requesting a dual-model review (Opus + Codex) of DPI-related code and spec docs in the WindowsEdgeLight repository 2. An explore agent was dispatched to find all DPI-related files in the repo 3. The main DPI spec doc, source code, manifest, and PR9 doc were read in full 4. Specific sections of MainWindow.xaml.cs were read (DPI declarations, CreateMonitorWindow, GetDpiForScreen, SetupWindowForScreen, OnDpiChanged, HandleMouseMove, MoveToNextMonitor) 5. Two background code-review agents were launched in parallel: one with claude-opus-4.6 and one with gpt-5.1-codex 6. Codex completed successfully with 2 issues found 7. Opus timed out after 633s with no response, was retried twice more (as code-review and general-purpose agents) with no response 8. A Sonnet 4.5 general-purpose agent was used as the second reviewer instead of Opus 9. Sonnet 4.5 completed successfully with a detailed analysis confirming the same 2 bugs Codex found, plus confirming 4 other concerns as non-issues 10. Final consensus results were presented to the user[Intent Mapping]
[Technical Inventory]
[Code Archaeology]
[Progress Assessment]
[Context Validation]
All critical information captured. The review is complete and findings delivered.
[Recent Commands Analysis]
The most recent operations were:
1. Conversation Overview: - Primary Objectives: User requested "/review" — specifically: "Take a look at the docs on DPI and use both Opus and Codex to do a complete review of the spec for our DPI work and the correctness of the code and only tell me issues that both models agree on." - Session Context: A code review of the DPI (display scaling) implementation in the WindowsEdgeLight WPF application. The user wanted a high-confidence review by requiring agreement between two different AI models before surfacing any issue. - User Intent Evolution: Straightforward single request. User checked in once ("how is it going") while waiting for background agents. No scope changes.- Technical Foundation:
- WPF (.NET 10.0): Desktop application with transparent overlay windows showing edge-light effects on monitors
- PerMonitorV2 DPI Awareness: Declared in both
- Win32 P/Invoke APIs:
app.manifest(<dpiAwareness>PerMonitorV2</dpiAwareness>) and.csproj(<ApplicationHighDpiMode>PerMonitorV2</ApplicationHighDpiMode>)GetDpiForMonitor(shcore.dll),MonitorFromPoint...Created from Copilot CLI via the copilot delegate command.
💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.