`eframe::NativeOptions::decorated` set to `false` incorrectly offsets UI on Windows 10

[Aely0]

Describe the bug
When running an egui app natively on Windows 10 with eframe::NativeOptions::decorated set to false, the visual render of the UI is offset towards right and bottom edges of the window, while interactions (like clicking a location) still correspond with the locations where UI elements should have been.

custom_window_frame.mp4

The offset zone is apparent more obviously with window transparency turned off.

To Reproduce
Run an egui app or any of the repository examples natively (commit e1f348e or later) with eframe::NativeOptions::decorated set to false.

Expected behavior
For the window interactions to correspond to the visually rendered UI and not for parts of the UI to be out of window bounds.

Desktop (please complete the following information):

• OS: Windows 10
• Version 22H2 (OS Build 19045.2546)
• Display driver: Intel(R) HD Graphics 4600 (20.19.15.4624 latest)

Additional context
This appears to be a winit issue for versions above 0.27.2 and was introduced into this repo at this point, when winit version was bumped up to 0.27.5 in Cargo.lock.

For those willing to downgrade to make use of the otherwise borked feature, you can clone the repo at this commit, which seems to be the latest commit that is still compatible with winit 0.27.2, lock winit to version 0.27.2 in the root Cargo.toml and update Cargo.lock with cargo update

[patch.crates-io]
winit = { git = "https://github.com/rust-windowing/winit", rev = "2e4338bb8dddf820c9bcda23d6b7a0d8a6208831" }

[Aely0]

Additional testing on two other machines running Windows 10 Pro (22H2 19045.2604)

• PC with RTX 3060
• Laptop with Intel HD Graphics 620

The custom_window_frame example worked as expected... So whatever is happening in my case, in general, is something rather inconsistent on which machines it will actually surface.

The root cause from within winit appears to come from this commit (the first commit after winit 0.27.2 release) and PR, that was meant to improve support for undecorated windows on Windows, yet introduced regressions, sprouting several issues (like this and others) that still appear to not been fully resolved.

[Aely0]

A minor testing side note, the Windows executable variant of example custom_window_frame also worked fine on Linux with Wine.

[thlstsul]

I had reproduce this bug, but use wgpu backend is worked fine.