Forms created on non-primary monitors with different DPI have incorrect font size

[filipnavara]

• .NET Core Version: 6.0 RTM

• Have you experienced this same bug with .NET Framework?: No

Problem description:

Forms that are launches on secondary screen with different DPI (eg. primary = 150% or 144, secondary = 100% or 96) have incorrectly scaled fonts.

Expected behavior:

Correctly scaled fonts.

Minimal repro:

WinFormsApp2.zip

Run the app, it will likely start on primary monitor. Clicking on the form with create a new form above the parent one. On primary screen it looks like this:

Move one of the windows on secondary screen a click on it. The new windows on the secondary screen look like this (upper left one on the screenshot is original form dragged from primary screen):

[filipnavara]

Ref: #4854, #5557

[filipnavara]

Dragging the form there and back between the monitors also messes up the fonts.

After dragging it back and forth between monitors two times:

The ScaledControlFont property is not invalidated properly and often returns stale values.

[merriemcgaw]

@filipnavara is this a regression?

[filipnavara]

Yes, it is a regression. You can change the TFM in the app to net5.0-windows to see how it behaved previously.

[dreddy-work]

@filipnavara, Thanks for reporting this. I am looking into it.

[dreddy-work]

Cached values for the property ScaledControlFont are indirectly fixed in the #5557. I do not expect this issue with latest bits from 7.0/main branch. I will be working on how to get this serviced. @filipnavara , did you try 7.0 bits here?

[filipnavara]

I'll retry with 7.0/main bits tomorrow when I am in the office with multi-monitor setup.

[filipnavara]

The font sizing is definitely working better on 7.0. I cannot verify it's 100% correct over VNC due to scaling issues with the remote desktop. Curiously, the forms are still created with a different size based on which displayed they were created on:

I think we had a workaround for that in our code but nothing I can verify at the moment or find quickly. At first I thought it's just typical ClientSize/Size issue but one of the windows is narrower and taller at the same time. I don't have explanation for that.

Would it make sense for me to try to backport specific PRs to the 6.0 branch and try running our full app with that?

[dreddy-work]

The font sizing is definitely working better on 7.0. I cannot verify it's 100% correct over VNC due to scaling issues with the remote desktop. Curiously, the forms are still created with a different size based on which displayed they were created on:

I think we had a workaround for that in our code but nothing I can verify at the moment or find quickly. At first I thought it's just typical ClientSize/Size issue but one of the windows is narrower and taller at the same time. I don't have explanation for that.

Would it make sense for me to try to backport specific PRs to the 6.0 branch and try running our full app with that?

Sure. Or if you can retarget to 7.0?

[filipnavara]

Or if you can retarget to 7.0?

Yeah, I can do that. I'd still need to build SWF myself to get version with 92921bb since it will take some time to propagate to feeds and/or installer package. We have some workarounds that would likely interfere and make it hard to see if it really helped or if we're hitting other issue.

I did initial build with 7.0 (w/o 92921bb) and it gave me mixed results. This issue with fonts looks likely to be fixed with 7.0/main but there are two other layout issues in the same control. One of them is related to 92921bb. The other one is bug in our code triggered by some other layout quirk which we didn't fully track down yet (but ultimately it's a bug in our code).

[dreddy-work]

there are two other layout issues in the same control. One of them is related to 92921bb.

If you have more details on other layout issue you are seeing, please share or open an issue against 7.0 and I will track it for 7.0 early preview. I am getting these two issues you reported serviced in 6.0.