PreferredMinMaxWidthHeight APIs don't handle different DPIs well

[niels9001]

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%)

1. Create a new WinUI app using 1.7-stable
2. Add the following code to MainWindow.xaml.cs:

OverlappedPresenter presenter = OverlappedPresenter.Create();
presenter.PreferredMinimumWidth = 800;
presenter.PreferredMinimumHeight = 800;
this.AppWindow.SetPresenter(presenter);

3. Press F5
4. Minimize the window
5. Use Win+Shift+Arrows to move the window around
6. 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

[mominshaikhdevs]

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: microsoft/WindowsAppSDK#5250

[daamenik]

@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.

[LucaCris]

I'm removing my duplicated issue, I'll follow needed solution here.

[Balkoth]

@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.