Thanks for your contribution!
Could you please:

• Add a small note about this change to the changelog
• Add your name to the list of contributors

Thanks!

Ok so having now had a closer look at this, I realized that our WinForms-Renderer does not quite support any DPI other than 96 (it uses a fixed 1:1 ratio between 1/96th inch device-independent units and pixels). This is not a problem with this PR per se, but a limitation of the GraphicsRenderContext implementation.

I think we could still merge this just to have a showcase of what is not supported at the moment and maybe at some point we'll want to update the GraphicsRenderContext accordingly.

What do you think @VisualMelon?

High DPI on WinForms is not something I've ever needed, so my input is limit to what I can find on SO and the msdn.

I think you are right that this would be worth including: the example browser is in some senses a separate concern, and it will be useful for testing the PlotView if it is updated to support variable Dpi.

I'd be happy to work on adding DPI support to GraphicsRenderContext. I'm not convinced the font sizes are correct in WinFroms (e.g. the 0.8 font factor should be 0.75?), but that's a question for another day.

Fix TreeView for HiDPI when full framework

#if NETFRAMEWORK
            FixTreeViewDpi();
#endif

High DPI on WinForms is not something I've ever needed, so my input is limit to what I can find on SO and the msdn.

Support in core looks better. And it looks like it will continue to improve dotnet/winforms#3202 (comment)

I don't have enough experience with WinForms to really comment on this. I can confirm that this works on my machine in the sense that the WinForms ExampleBrowser is displayed in a non-blurry way on all DPI settings I tested.
Plot rendering has some issues with incorrectly scaled plot elements on non-standard DPI, but as said previously, this is not an issue of this PR.

So if you don't see any problems @VisualMelon I think we could merge this.

I'm afraid that though I use winforms every day, I've never had to deal with variable DPI, so I'm guessing at everything really.

Testing with the Scaling option in Windows 10 (I don't have a high DPI screen), the .NET Framework text is much larger than the .NET Core text. Disabling the .NET Framework specific stuff seems to reduce (but not remove) the difference. Is this how it behaves for other people? (The .NET Framework stuff looks OK for me with the "Let Windows try to fix apps so they're not blurry" option; Core looks good).

The Framework specific stuff doesn't modify the checkboxes. If it is necessary to perform manual adjustments (which doesn't seem to be the case on my machine: @rstm-sf could you explain the idea?) it should ideally affect everything. The checkboxes can be made smart by setting SutoSize = true, and changing the panel at the bottom to resize/layout with them (e.g. swap it for an auto-sizing flow panel).

Testing with the Scaling option in Windows 10 (I don't have a high DPI screen)

Sorry, I missed it. Yes, we need to add the definition that dpi is changed and only then increase the treeview

could you explain the idea?

Winforms does not fully support hidpi, so we need to manually increase some controls. But it is possible that I missed some option ...

Although, I remembered why I did not. At 100%, scaleFactor = 1 should turn out and this is exactly what happens for me. I don’t know why you have this behavior... I need to think about it, as I noticed that if I change the dpi, the winforms does not respond to this

I should clarify that the text is only larger with scale factor > 100%: nothing seems to regress at the default DPI.

Feel free to ping me if you want anything tested.

I tried to set system aware, maybe this will help?

Last change, so as not to fix with dpi == 96

I'll take another proper look at this sometime in the next few days, and I'll put together a fix for the checkboxes which we can either merge into this or I'll just push through as a separate PR.

Taking a quick look just now (because I'm contemplating adding DPI support to GTK if it needs it), the tree view is still too big when using .NET Framework.

If I disable FixTreeViewDpi, with 175% scaling and NET Framework I get this (which looks fine):

With it enabled, I get this:

Similar behaviour with NET Core when I remove the NETFRAMEWORK check in InitTree

Thanks for the clarification! This problem also reproduces for me, but at 125 everything is fine