Windows 11 24H2 mixed-DPI drag still grows windows in 0.30.13

[wnunezc]

Description

This is a follow-up to the closed issue #4041. The same Windows mixed-DPI drag/resize feedback loop is still reproducible with winit 0.30.13 on Windows 11 24H2.

When a maximized window is dragged from a 125% scaled primary monitor to a 100% scaled monitor, the restored window can grow to an extremely large size and remain attached to the original monitor instead of landing on the target monitor. This also reproduces through eframe 0.29.1, because it uses winit underneath.

Monitor layout used for reproduction

• DISPLAY5: 1920x1080, 100% scale, positioned left of primary: (-1920,0)-(0,1080)
• DISPLAY1: 1920x1080, 125% scale, primary: (0,0)-(1920,1080)
• DISPLAY6: 1920x1200, 125% scale, positioned right: (1920,-65)-(3456,895)

Minimal repro

Two minimal binaries were tested:

1. Raw winit 0.30.13:

use winit::{
    application::ApplicationHandler,
    dpi::LogicalSize,
    event::WindowEvent,
    event_loop::{ActiveEventLoop, EventLoop},
    window::{Window, WindowAttributes, WindowId},
};

#[derive(Default)]
struct App { window: Option<Window> }

impl ApplicationHandler for App {
    fn resumed(&mut self, event_loop: &ActiveEventLoop) {
        if self.window.is_none() {
            let attrs = WindowAttributes::default()
                .with_title("repro_winit")
                .with_inner_size(LogicalSize::new(1000.0, 650.0))
                .with_maximized(true);
            self.window = Some(event_loop.create_window(attrs).expect("create window"));
        }
    }

    fn window_event(&mut self, event_loop: &ActiveEventLoop, _id: WindowId, event: WindowEvent) {
        if matches!(event, WindowEvent::CloseRequested) {
            event_loop.exit();
        }
    }
}

fn main() {
    let event_loop = EventLoop::new().expect("event loop");
    let mut app = App::default();
    event_loop.run_app(&mut app).expect("run app");
}

2. eframe 0.29.1 with ViewportBuilder::with_maximized(true) also reproduces the same behavior.

Both binaries used a PerMonitorV2 manifest.

Observed measurement without patch

Raw winit 0.30.13, after dragging from DISPLAY1 to the left monitor:

Before:
  ShowCmd: 3
  Rect: (-9,-9)-(1929,1029)
  Normal: (32,32)-(1300,892)
  Monitor: \\.\DISPLAY1
  DPI: 120

After drag:
  ShowCmd: 1
  Rect: (-1329,75)-(2545,2701)
  Size: 3874x2626
  Monitor: \\.\DISPLAY1
  DPI: 120

eframe 0.29.1 showed the same class of failure:

After drag:
  Rect: (-1164,75)-(1935,2176)
  Size: 3099x2101
  Monitor: \\.\DISPLAY1
  DPI: 120

Local patch tested

The issue disappears when WM_DPICHANGED while WindowFlags::MARKER_IN_SIZE_MOVE uses the Windows-provided suggested_rect directly instead of applying the current conservative rect / monitor nudge logic.

Patch tested locally against winit 0.30.13:

let new_outer_rect: RECT;
if dragging_window {
    new_outer_rect = suggested_rect;
} else {
    // existing conservative_rect + monitor nudge logic
}

Observed measurement with local patch

Raw winit 0.30.13 patched:

Before:
  ShowCmd: 3
  Rect: (-9,-9)-(1929,1029)
  Normal: (160,160)-(1428,1020)
  Monitor: \\.\DISPLAY1
  DPI: 120

After drag:
  ShowCmd: 1
  Rect: (-1417,79)-(-403,767)
  Size: 1014x688
  Monitor: \\.\DISPLAY5
  DPI: 96

eframe 0.29.1 using the patched winit also behaves correctly:

After drag:
  Rect: (-1404,79)-(-390,767)
  Size: 1014x688
  Monitor: \\.\DISPLAY5
  DPI: 96

Notes

This matches the analysis already posted in #4041: during WM_DPICHANGED, the current monitor check / nudge logic can keep the window on the old monitor, trigger another DPI change, and repeatedly enlarge the window. Microsoft's WM_DPICHANGED guidance recommends applying the suggested rectangle from lParam with SetWindowPos.

Reference: https://learn.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged

Platform

• Windows 11 24H2
• winit 0.30.13
• Reproduces with raw winit and through eframe 0.29.1
• Process DPI awareness: Per Monitor Aware (GetProcessDpiAwareness == 2)

[wnunezc]

Follow-up from MFA-Forge Windows validation:

A vendored copy of winit 0.30.13 with the WM_DPICHANGED mixed-DPI drag adjustment fixes the reproduction on a 3-monitor Windows 11 setup:

• 1920x1080 @ 100%
• 1920x1080 @ 125% (primary)
• 1920x1200 @ 125%

With the patch, dragging the app between the 125% primary display and the 100% display no longer causes flicker, mouse-capture loss, or runaway window growth. Repeated open/close restore cycles also stay stable.

For MFA-Forge this is still release risk: shipping a vendored winit override is not ideal for a public MSI, even if the delta is narrow and based on the official 0.30.13 source. We are documenting it as a temporary hotfix and plan to remove the [patch.crates-io] override as soon as an official upstream release contains the fix.

This looks like a regression-sensitive Windows mixed-DPI path, so an upstream fix would be strongly preferred over downstream vendoring.

[bigtree108-dmytro]

As promised in #4704, here are two-screen results for 0.30.13 with and without #4341.

Setup: Windows 11 build 26200, a 1920x1200 laptop screen at 125% (primary, on the right) and a 3440x1440 screen at 100% on the left, so the same arrangement as in this issue. The window is a plain winit example like the one above, with logging of every Moved, Resized and ScaleFactorChanged. The drags were done by hand, since a scripted drag never enters the move loop. I compared three builds:

• 0.30.13 as released
• 0.30.13 with prevent incorrect resizing/shifting of window when dragging onto monitor with different DPI #4341 cherry-picked. Only the paths change: the gate and the extracted apply_win10_dpi_adjustment are identical to 488c036, and the code it replaces on 0.30.x is identical to what it replaced on master.
• 0.30.13 with the one-line change from On Windows, read the new scale factor's monitor from the suggested rect #4704, which reads the monitor from suggested_rect instead of MonitorFromWindow

	0.30.13	with #4341	one-line change
drag by hand, normal window	9 scale changes in 0.2 s, window grew from 1000x650 to 1572x1038 logical	1 change per crossing, no growth	1 change per crossing, no growth
drag by hand, maximized (the case here)	7 scale changes in 40 ms on the way back	1 change per crossing	1 change per crossing
Win+Shift+Arrow to the other screen	left across both screens, 60/40 (#4573)	lands on the other screen	lands on the other screen
Win+Arrow snap across screens	left across both screens	exactly the rectangle Windows snaps to	wrong size, ended up 2150x1739 on the 1920x1200 screen

So on Windows 11 #4341 stops the back-and-forth in both drags, the growth that comes with it, and the straddling from #4573, and it's the only one of the three that gets snapping right. In my maximized run 0.30.13 happened to settle at the right size, so I saw the back-and-forth there but not the growth reported above. The one-line change doesn't handle snapping, which confirms closing #4704 was the right call.

Since #4637 was closed because backports aren't sent that way, could #4341 be picked up when the next 0.30 release is cut? The cherry-pick I tested is here in case it saves time: bigtree108-dmytro@42b2007

One difference I noticed while testing: with #4341 on Windows 11, a size the application requests through InnerSizeWriter in ScaleFactorChanged is ignored, although the request returns Ok. 0.30.13 honors it, and master behaves like the cherry-pick. That's a separate question from this issue, so I'm only mentioning it here.

Not tested: Windows 10, other scale pairs, and screens arranged vertically.

[bigtree108-dmytro]

The ignored size request I mentioned above is now #4721, with a proposed fix.