microsoft
PreferredMinMaxWidthHeight APIs don't handle different DPIs well
Describe the bug
When the minimum size is set on a window, using the new APIs shipping with 1.7, and a window gets moved to another screen the window size does not get adjusted.
Steps to reproduce the bug
My setup: Screen 1: 1920x1080 (100%) Screen 2: 2048x1152 (150%)
- Create a new WinUI app using 1.7-stable
- Add the following code to
MainWindow.xaml.cs:
OverlappedPresenter presenter = OverlappedPresenter.Create();
presenter.PreferredMinimumWidth = 800;
presenter.PreferredMinimumHeight = 800;
this.AppWindow.SetPresenter(presenter);
- Press F5
- Minimize the window
- Use Win+Shift+Arrows to move the window around
- Window can be resized again on the screen with the larger DPI.
The first window shows the bug. The second window (AI Dev Gallery) uses WinUIEx and is rendering as expected.
Expected behavior
The window should render properly. See the second part of the gif above for the expected result (the AI Dev Gallery window)
Screenshots
No response
NuGet package version
Windows App SDK 1.7.0: 1.7.250310001
Packaging type
Packaged (MSIX)
Windows version
Windows 11 version 24H2 (22621, October 2024 Update)
IDE
Visual Studio 2022-preview
Additional context
No response
3rd party devs can create 3rd party libs that works as expected. (WinUIEx).
what a load of clusterf**k MS' WinUI3 devs are! what a shame!
ref: https://github.com/microsoft/WindowsAppSDK/discussions/5250
@niels9001 This is due to the fact that, like other sizing-related AppWindow APIs, PreferredMinMaxWidthHeight work with screen coordinates. I can see the argument to diverge from that convention, though, or at least only make it matter when setting the properties, since the window is resized to match DPI when dragged to a different monitor.
@niels9001 This is due to the fact that, like other sizing-related AppWindow APIs, PreferredMinMaxWidthHeight work with screen coordinates. I can see the argument to diverge from that convention, though, or at least only make it matter when setting the properties, since the window is resized to match DPI when dragged to a different monitor.
It makes absolutely no sense to not adjust these values when moving between displays with different DPIs. The values set for PreferredMinMaxWidthHeight have to be interpreted as 100% (GetDpiForWindow(hwnd) / 96F = 1) so it auto-adjusts when the display the windows is moved to has differing DPI.
If the framework does not do this by itself, then the developer has to intercept WM_DPICHANGED and adjust the values for PreferredMinMaxWidthHeight on every change.
And if you force me to do this, then im keeping my current solution of intercepting WM_GETMINMAXINFO and relying on my own solution, because i know that it works the way it should.
Honestly i am questioning, if the developer implementing this feature, ever tried it on multiple monitors with different DPIs. And if he did, what was the motivation to keep it this way.
