Skip to content

prevent incorrect resizing/shifting of window when dragging onto monitor with different DPI#4341

Merged
kchibisov merged 2 commits into
rust-windowing:masterfrom
moooozi:win32-dpi-fix
Aug 24, 2025
Merged

prevent incorrect resizing/shifting of window when dragging onto monitor with different DPI#4341
kchibisov merged 2 commits into
rust-windowing:masterfrom
moooozi:win32-dpi-fix

Conversation

@moooozi
Copy link
Copy Markdown
Contributor

@moooozi moooozi commented Aug 23, 2025

  • Tested on all platforms changed
  • Added an entry to the changelog module if knowledge of this change could be valuable to users
  • Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
  • Created or updated an example program if it would help users understand this functionality

The original PR 4119 appears to be abandoned. This PR aims to recreate the fix, following the project guidelines.

This PR fixes this issue: #4041

The code I deleted has a validation to check if the new window bounds which Windows is suggesting to move the monitor to is actually on the monitor which triggered the WM_DPI_CHANGED event. If that validation fails, it tried to move the window such that it will be on the monitor which triggered the WM_DPI_CHANGED event. However, this validation was buggy and was actually causing this bug. It was moving the window off of the intended monitor. It seems this is no longer necessary. For example, Chromium's DPI changed handler does not contain an analogous check.

Before
https://www.loom.com/share/aefc5dc1027a42fc8f462c23621ce9a5

After
https://www.loom.com/share/81351dcb5938463c8bb60a66b2a0641b

I've created a similar fix for TAO but kept the logic conditionally for Windows 10 (build < 22000) just to be safe. But I'm not sure if it is worth to keep that much logic just for minimal positioning optimizations, especially now that Windows 10 will soon reach EOL.

Related PR and issues (TAO seems still uses the same logic since it was forked from winit, so I think they are relevant):

tauri-apps/tao#1056
tauri-apps/tao#1053
tauri-apps/tauri#10263
tauri-apps/tauri#12626

Comment thread winit/src/changelog/unreleased.md Outdated
Comment thread winit/src/changelog/unreleased.md Outdated
Comment thread winit-win32/src/event_loop.rs Outdated
For earlier Windows 10 builds (pre-22000), a workaround was necessary to fix dragging window onto a monitor with different DPI. This commit makes the old DPI workaround  only applied conditionally. Applying it globally on newer systems breaks DPI switching.
@moooozi moooozi requested a review from kchibisov August 24, 2025 03:50
@kchibisov kchibisov merged commit 488c036 into rust-windowing:master Aug 24, 2025
57 checks passed
@vorporeal
Copy link
Copy Markdown

Glad this got merged! Any rough estimate on when we'll get an updated winit release that contains this?

@madsmtm madsmtm added the DS - win32 Affects the Win32/Windows backend label Sep 4, 2025
danielpancake added a commit to danielpancake/winit that referenced this pull request Mar 21, 2026
Backport of PR rust-windowing#4341 to 0.30.x: make the conservative-rect + monitor-nudging
logic conditional on Windows 10 (build < 22000). On Windows 11+, use the
OS-provided suggested_rect directly, avoiding the cascading WM_DPICHANGED
feedback loop that causes the window to grow indefinitely.

Fixes rust-windowing#4041
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

DS - win32 Affects the Win32/Windows backend

Development

Successfully merging this pull request may close these issues.

4 participants