Incorrect DPI scaling on Windows

[valaphee]

While testing DPI scaling with two monitors on Windows 11, one running at 4k (150% scaling) and the other at 2k (100% scaling) and both being 32", I noticed that the window size is 50% larger on the 4k one, which should be physically the same size.

And the conversion is also "lossy" because when moving the window between both monitors it's getting larger by one pixel

// new_dpi_x, new_scale_factor
144 1 1.5
PhysicalSize { width: 1208, height: 920 } PhysicalSize { width: 1812, height: 1380 }
96 1.5 1
PhysicalSize { width: 1201, height: 901 } PhysicalSize { width: 801, height: 601 }
144 1 1.5
PhysicalSize { width: 1210, height: 921 } PhysicalSize { width: 1815, height: 1382 }
96 1.5 1
PhysicalSize { width: 1203, height: 903 } PhysicalSize { width: 802, height: 602 }
144 1 1.5
PhysicalSize { width: 1211, height: 923 } PhysicalSize { width: 1817, height: 1385 }
96 1.5 1

It seems that both monitors are using 4k logical resolution, but I assume that's Windows 11?

[stefnotch]

I don't exactly understand what the issue is, so please bear with me:

The monitors are 4k and 2k (physically).
The 4k monitor has a 150% DPI scaling, so that everything there remains reasonably sized.
To turn a physical size into a logical one, one divides by the DPI scale. An alternative way of putting this is that a logical pixel on the 4k monitor is 150% larger than usual.

So the window always has the same logical size, but a different physical size. (Physical size as in the number of physical pixels.)

What exactly is going wrong?

The conversion being lossy is unfortunate. I'm guessing that Windows itself is to blame for that, but I'd have to check.

[valaphee]

Exactly, but Windows seems to also use the logical size, which results in the window being 150% larger (300% in total) as Winit also scales the window.

[stefnotch]

@valaphee Could you post a screenshot of that? From the output, it's not entirely obvious.

[valaphee]

Sure, the calculator is for reference, its the same window just moved and both screenshots combined.

[valaphee]

Did some experimenting, the size is automatically scaled by the OS, but don't know if this is Windows 11 specific, I assume that at some point the scaling had to work, or its a regression.

P.S. is Windows 11 related as the size is now automatically scaled (but its also an inconsistent behavior as for changing the dpi without moving the window the size must be scaled manually)

[sidit77]

The window scaling seems to be completely broken for me right now when moving a window between monitors.

Video

The last part of the video is me trying to move the window between monitors using hotkeys (Win + Shift + Left/Right)

OS: Windows 11 24H2 (26100.2161)
Primary Monitor: 3840x2160 @ 150%
Second Monitor: 1920x1080 @ 100%

[sidit77]

I did some debugging and discovered what causes the issues I've been experiencing.

In this code section winit attempts to push the window fully on the new monitor. Unfortunatly, MonitorFromWindow(window, MONITOR_DEFAULTTONULL) still returns the old monitor for me. As a result winit will push the window back to the old monitor and trigger another DPI change. I'm not sure why this code existst in the first place, it seems to come from #1130 but I can't find any reason behind it.

I feel like this isn't actually releated to the sizing issue discussed here should I create a new issue?

[SimonORorke]

@sidit77 wrote:

I did some debugging and discovered what causes the issues I've been experiencing.

In this code section winit attempts to push the window fully on the new monitor. Unfortunatly, MonitorFromWindow(window, MONITOR_DEFAULTTONULL) still returns the old monitor for me. As a result winit will push the window back to the old monitor and trigger another DPI change

In slint-ui/slint#11073, a Slint bug that I believe is caused by this one, @Rumia-Channel reports finding the following amendment to the code @sidit77 references to be an effective fix.

@Rumia-Channel wrote:
I patched the Windows WM_DPICHANGED handling in winit like this:

Before:

let new_dpi_monitor = unsafe { MonitorFromWindow(window, MONITOR_DEFAULTTONULL) };

After:

let new_dpi_monitor = unsafe {
    MonitorFromRect(&suggested_rect, MONITOR_DEFAULTTONULL)
};

So instead of determining the target monitor from the current window, I used the monitor implied by the WM_DPICHANGED suggested rect.

That stopped the DPI ping-pong during dragging, and the window started preserving its logical size correctly when moving between monitors.