Setting a window to full screen can cause the window to not cover the full window if a DPI change is involved

[npwoods]

Description

There seems to be a problem where on Windows, a call to Window::set_fullscreen() will not necessarily result in the window covering the screen (specifically, the height is slightly shorter than it should be) if the following conditions apply:

• The target monitor has a different DPI than the old monitor
• The window in question has a menu bar

This is illustrated in the attached demo where a window pops up and it does the following:

• Press X, the window will become full screen on display \\.\DISPLAY2 (this needs to be edited to point to a display with a different resolution than the primary monitor)
• Press Y, and a menu bar will be added
  winit_bug_demo.zip

The problem seems to be that when SetWindowPos() is invoked to make the window full screen, WM_DPICHANGED will be sent to the window. I don't quite follow the maze of calculations within util::WindowArea::Inner::get_rect(), but having a menu bar seems to result in the inner rect being offset from the top. This seems to be correct, but ultimately the call to SetWindowPos() within WM_DPICHANGED makes the window smaller than it should be.

It is also not clear to me if the handler for WM_DPICHANGED should be doing anything if the DPI change is the result of calling Window::set_fullscreen() or any other programmatic call.

I hope this helps!

Windows version

Windows 10

Winit version

0.30.11

[npwoods]

Some more analysis. In my particular case, my window starts on \\.\DISPLAY1 which is scaled at 150%, and I am setting it to full screen on \\.\DISPLAY2 which is scaled at 100%.

Here is the gotcha:

• margin_top is calculated base on the lParam of the WM_DPICHANGED window event. This rectangle comes from the SetWindowPos() call made by Window::set_fullscreen(). The resulting margin_top value is correctly 20, in line with the new position on the new display.
• However, old_physical_inner_rect seems to be calculated incorrectly. The position is retrieved with util::WindowArea::Inner.get_rect(window), which seems to retrieve the new position, but the calculation for actually getting the rectangle (using the ClientToScreen() and GetClientRect() Win32 calls), seems to be calculated based on the old DPI. This makes sense because WM_DPICHANGED is the message that applies the DPI change.

The discrepancy between margin_top and old_physical_inner_rect creates a situation where a calculation that should really be a no-op makes the so-called "full screen" window to not have the proper height.

The logic for WM_DPICHANGED seems to be all about responding to "external" changes in the Windows DPI (e.g. - the user changing the resolution of a monitor). I think that winit on Windows needs a mechanism to prevent this logic from being executed when the DPI change is the result of a programmatic manipulation of the window.

[npwoods]

Crude PR: #4305