[Multi-Monitor] PerMonitorV2 autoscale lead to wrong ClientSize.

[kirsan31]

.NET version

8.0.7

Did it work in .NET Framework?

No.

Did it work in any of the earlier releases of .NET Core or .NET 5+?

.Net 5 - 7 have similar problem but the difference is match smaller. Can't test 9.0RC1 due to build error:

(ResolvePackageAssets target) -> C:\Program Files\dotnet\sdk\9.0.100-rc.1.24452.12\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1060: Error reading assets file: Error loading lock file 'e:\Projects\Other\core tests\WinFormsPerMonitorV2\obj\project.assets.json' : Could not load file or assembly 'System.Text.Json, Version=8.0.0.4, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

Issue description

PerMonitorV2 app.

• launch on screen with dpi A will result in ClientSize = CLS1. The same as launch SystemAware app.
• launch on screen with dpi B and then drag to screen A will result in ClientSize = CLS2.

And CLS1 != CLS2.

Steps to reproduce

WinFormsPerMonitorV2.zip

• launch app, change scale in windows settings.
• launch app again - compare ClientSize values.

or

• Change scale in windows settings to other then 100%.
• launch app, change scale in windows settings to100%.
• launch app again - compare ClientSize values.

[Tanya-Solyanik]

@Olina-Zhang could you please find what PR in NET8 had regressed this behavior and if the quirks can help with this issue.

[kirsan31]

@Tanya-Solyanik

@Olina-Zhang could you please find what PR in NET8 had regressed this behavior and if the quirks can help with this issue.

This is not regression from .Net6 (may be earlier?):

Did it work in any of the earlier releases of .NET Core or .NET 5+?

.Net 6 and 7 have same problem but difference is bigger. Can't test 9.0RC1 due to build error:

[Tanya-Solyanik]

@kirsan31 - we want to see what caused the bigger difference.

[Philip-Wang01]

@Tanya-Solyanik This behavior is regression from: https://github.com/dotnet/winforms/pull/7973 and here are the test results. Somewhat strangely, when running the application multiple times, it is possible to get the same results as before. Please check out the video.

https://github.com/user-attachments/assets/dab2b830-33a3-45b5-a435-b8b9c7d0d0b6

[kirsan31]

This behavior is regression from: #7973 and here are the test results.

Sorry but I still don't get why you call this regression. 🤷‍♂️ In .Net 8 it's become more accurate then before, but still not 100% accurate. Correct size with 125% dpi is 715x644; And I think that more accurate to use second test mechanics from my 1 post (to compare with 100% DPI settings (for that we know size that we set in designer 626x483)):

• Change scale in windows settings to other then 100%.
• launch app, change scale in windows settings to100%.
• launch app again - compare ClientSize values.

[Olina-Zhang]

Correct size with 125% dpi is 715x644;

One question: why the correct size on 125% is 715x644 based on 100%: 626x483, not 783x604 on 125%?

[kirsan31]

@Olina-Zhang Omg - this is the right question! 715x644 is systemaware starting size with 125% dpi. And this size the same from .Net5 to .Net8! So we have new question here: Is 715x644 systemaware 125% dpi scaling correct for 626x483? It's seems that no...

All my previous conclusions was made comparing to systemaware scaling and in this terms .Net8 PerMonitorV2 more close to it than .Net5-7.

[RussKie]

Sorry but I still don't get why you call this regression. 🤷‍♂️ In .Net 8 it's become more accurate then before, but still not 100% accurate. Correct size with 125% dpi is 715x644;

642 * 1.25 = 802.5 522 * 1.25 = 652.5

[kirsan31]

@RussKie

Sorry but I still don't get why you call this regression. 🤷‍♂️ In .Net 8 it's become more accurate then before, but still not 100% accurate. Correct size with 125% dpi is 715x644;

642 * 1.25 = 802.5 522 * 1.25 = 652.5

Yea I already got it - explained in my previous post above (I couldn't imagine that systemaware scaling is wrong).

[kirsan31]

Opened a new issue #12270. I think we need to solve #12270 before trying to fix current one.

[merriemcgaw]

@KlausLoeffelmann - this was one you wanted to look at.