[HighDPI] WinForms changes the true size of controls with system DPI awareness

[OliaG]

• .NET Core Version:

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

Problem description:
Copied from tweet thread: https://twitter.com/awakecoding/status/1389943462871633922?s=20

A 1920x1080 is reported as 4800x2700 with 250% DPI scaling, yet the true size of the control is still 1920x1080 (if I draw using the reported size, it is 250% larger than the real size). This means that when trying to automatically size the contents to the control size, it is always 250% too big when the system DPI scaling is set to 250%. I wouldn't mind if drawing at 250% gave the correct result, but it doesn't. I have to downscale the reported control size:

The odd thing is that by applying this workaround, I get a correct result even on a mixed DPI system. I can move the control between screens and it still gets the correct size by doing the inverse operation. I would have expected maybe an incorrect result on the high dpi screen?

Minimal repro:
a primary display in the middle with a gigantic resolution (and huge scaling factor - 250%). Add a full HD display on the left (it'll have negative coordinates) and another one to the right to get mixed DPI Smiling face with open mouth and cold sweat

[dreddy-work]

Can we get the sample app with his experiment here?

[dreddy-work]

@OliaG , I would need a test application here to understand this better. Is it possible to ping the user on twiiter and ask for it?

[awakecoding]

@dreddy-work I don't have a simple test application (nor the time to prepare one, unfortunately) but would a free closed source application help in your investigation? I implemented a workaround in Remote Desktop Manager to fix the incorrect coordinates, all you'd need is an RDP server to connect to to replicate the bug (it was in an embedded RDP window using FreeRDP, not the Microsoft ActiveX)

[awakecoding]

Here are the download links to the last version of RDM Free without the workaround I applied (2021.1.26):

https://cdn.devolutions.net/download/Setup.RemoteDesktopManagerFree.2021.1.26.0.msi
https://cdn.devolutions.net/download/Devolutions.RemoteDesktopManagerFree.Bin.2021.1.26.0.zip

To replicate the issue, create an embedded RDP entry, and then go in the Advanced tab to select "RDP (FreeRDP latest)". You will only get the issue with FreeRDP because the the RDP ActiveX does its own DPI handling.

The same issue affects the Apple Remote Desktop / VNC embedded session types, so if you have one of those available instead you can give it a try. I'm sorry I don't have more to provide right now.

[dreddy-work]

Thank you @awakecoding for the info. I ran the tool but I admit that this is the first time i am using this tool and have no idea on how this works and what to expect after creating RDP session. Do you mind generating a GIF by repro'ing the issue with this tool?

[awakecoding]

The problem should appear as the embedded RDP desktop size being much larger than it should be instead of matching the embedded window size. By default we take the size of the embedded window and pass it to FreeRDP, but it is incorrectly reported, leading to a much larger size. You can toggle with the regular RDP engine (RDP ActiveX) and you should see a difference - the Microsoft RDP ActiveX can natively handle the DPI unlike FreeRDP.

Here are more details: https://twitter.com/awakecoding/status/1389943462871633922?s=19

[awakecoding]

Ok, here's a screenshot showing RDM 2020.1.26 with an embedded RDP session using the RDP ActiveX (select RDP Version "latest" in the Advanced tab). The Microsoft RDP ActiveX natively handles DPI rendering and somehow handles the size of the parent window correctly, but we have no control (or knowledge) of how it does it. The FreeRDP engine is ours (FreeRDP is my project btw) and the problem is not with FreeRDP, but with the reported window size that is way too large. The intended behavior is to request a resolution matching the embedded window, which we do, but WinForms gives us an upscaled size that doesn't match the actual size when we render in it, causing what you see in the second screenshot.

One more thing: in the "bad" screenshot, the DPI sent to the server corresponds to the system DPI. The resolution is quite large, but the icons are rendered larger to compensate for the DPI. This is just a value sent to the server, but since we don't render high dpi natively client-side, I've fixed it by setting it to 100% scaling. The only difference if you set 100% scaling without changing the window size reported by WinForms is you'll get a very large desktop size with everything rendered very small in it. The real issue here is the reported window size that WinForms gives us.

Here are important things you need to know: RDM currently runs in system DPI mode, we don't implement per-monitor DPI yet. I confirm that when launching RDM in per-monitor DPI the reported window size is the good one, so I apply my workaround only in system DPI mode. Let me know if you can replicate the issue like the one in my screenshots, then we can try to have you replicate the same issue outside of RDM. The problem is made worse with large system DPI scaling - mine is 250%. If you have 125% or 150% the embedded RDP window will be slightly larger and much less bad than my screenshot, but it still won't match the embedded window size.