.NET Framework 4.7 - High DPI Improvements #374

Closed
richlander opened this Issue Apr 5, 2017 · 14 comments

Comments

Projects
None yet
@richlander
Member

richlander commented Apr 5, 2017

Please share your feedback on the High DPI improvements for Windows Forms applications in the .NET Framework 4.7. We are planning the next set of updates and would like you to help us prioritize the set of improvements to make next for High DPI.

See today's .NET Framework 4.7 Announcement, which describes Windows Forms High DPI improvements.

You can read the .NET Framework 4.6.2 Announcement to learn about High DPI improvements for WPF applications.

General feedback can be provided at .NET Framework 4.7 Feedback (#393).

@kecjhL9biL8S

This comment has been minimized.

Show comment
Hide comment
@KindDragon

This comment has been minimized.

Show comment
Hide comment
@KindDragon

KindDragon Apr 13, 2017

See today's .NET Framework 4.7 Announcement, which describes Windows Forms High DPI improvements.

Hi,
I'm one of developers GitExtensions Git client

Two most annoying issues for me with Windows Forms High DPI:

  1. When use DPI scaling for my display, I can't easily save my WinForm without scaling (96 DPI). I can't disable System Aware scaling for Visual Studio (compatibility tab missing in devenv.exe properties). If I save my WinForm on high DPI display it produces some artifacts when you try use this form on display with different DPI.
  2. I can't easily find out my WinForm issues with different DPI. Would be great if VS allow switching between different DPI in WinForms Designer (with optional stretching to current display DPI)

KindDragon commented Apr 13, 2017

See today's .NET Framework 4.7 Announcement, which describes Windows Forms High DPI improvements.

Hi,
I'm one of developers GitExtensions Git client

Two most annoying issues for me with Windows Forms High DPI:

  1. When use DPI scaling for my display, I can't easily save my WinForm without scaling (96 DPI). I can't disable System Aware scaling for Visual Studio (compatibility tab missing in devenv.exe properties). If I save my WinForm on high DPI display it produces some artifacts when you try use this form on display with different DPI.
  2. I can't easily find out my WinForm issues with different DPI. Would be great if VS allow switching between different DPI in WinForms Designer (with optional stretching to current display DPI)
@Yecats

This comment has been minimized.

Show comment
Hide comment
@Yecats

Yecats Apr 13, 2017

Contributor

Thanks for the feedback @KindDragon.

Regarding 1: Assuming that i'm understanding you correctly, it sounds like you want to turn off DPI scaling for VS. We already have the VS experience with HDPI as an area we want to address in a future release as we know it's problematic. In the meantime, you should be able to disable it. Here's a few alternative solutions that may help: https://code4ward.net/2016/11/29/visual-studio-winforms-designer-on-highdpi/

Regarding 2: This is a great suggestion! I've already passed it along to the team and we'll keep it on our list to investigate.

I hope that helps, but please don't hesitate to let us know if there's anything else that comes up.

Contributor

Yecats commented Apr 13, 2017

Thanks for the feedback @KindDragon.

Regarding 1: Assuming that i'm understanding you correctly, it sounds like you want to turn off DPI scaling for VS. We already have the VS experience with HDPI as an area we want to address in a future release as we know it's problematic. In the meantime, you should be able to disable it. Here's a few alternative solutions that may help: https://code4ward.net/2016/11/29/visual-studio-winforms-designer-on-highdpi/

Regarding 2: This is a great suggestion! I've already passed it along to the team and we'll keep it on our list to investigate.

I hope that helps, but please don't hesitate to let us know if there's anything else that comes up.

@KindDragon

This comment has been minimized.

Show comment
Hide comment
@KindDragon

KindDragon Apr 13, 2017

Here's a few alternative solutions that may help: https://code4ward.net/2016/11/29/visual-studio-winforms-designer-on-highdpi/

Thank you 👍 That almost what I needed for updating my Form's

Regarding 2: This is a great suggestion! I've already passed it along to the team and we'll keep it on our list to investigate.

Thank you

Here's a few alternative solutions that may help: https://code4ward.net/2016/11/29/visual-studio-winforms-designer-on-highdpi/

Thank you 👍 That almost what I needed for updating my Form's

Regarding 2: This is a great suggestion! I've already passed it along to the team and we'll keep it on our list to investigate.

Thank you

@JoeErickson

This comment has been minimized.

Show comment
Hide comment
@JoeErickson

JoeErickson Apr 14, 2017

We spent a couple of days looking into the possibility of adding high dpi support to our SpreadsheetGear for .NET Windows Forms controls and Workbook Designer but at this point we are punting for now because the MDI form and related controls do not work with high dpi - especially when dragging an MDI form between multiple monitors running at different DPI.

Is Microsoft going to fix MDI forms to fully support high dpi?

Thank you.

We spent a couple of days looking into the possibility of adding high dpi support to our SpreadsheetGear for .NET Windows Forms controls and Workbook Designer but at this point we are punting for now because the MDI form and related controls do not work with high dpi - especially when dragging an MDI form between multiple monitors running at different DPI.

Is Microsoft going to fix MDI forms to fully support high dpi?

Thank you.

@Yecats

This comment has been minimized.

Show comment
Hide comment
@Yecats

Yecats Apr 17, 2017

Contributor

@JoeErickson
Thanks for the feedback! HDPI MDI support is planned currently.

Contributor

Yecats commented Apr 17, 2017

@JoeErickson
Thanks for the feedback! HDPI MDI support is planned currently.

@JoeErickson

This comment has been minimized.

Show comment
Hide comment
@JoeErickson

JoeErickson Apr 17, 2017

@staceyhaffner
Is there any way to track the progress on HDPI MDI support and / or be involved in early releases?

@staceyhaffner
Is there any way to track the progress on HDPI MDI support and / or be involved in early releases?

@juanjoseluisgarcia

This comment has been minimized.

Show comment
Hide comment
@juanjoseluisgarcia

juanjoseluisgarcia Apr 26, 2017

Dynamic Resources file. It would be nice if winforms could detect the dpi and choose a .Resx file that scales to 300%. So if it's normal dpi the .Resx file is chosen. When on high dpi the .300.Resx file is used.

Dynamic Resources file. It would be nice if winforms could detect the dpi and choose a .Resx file that scales to 300%. So if it's normal dpi the .Resx file is chosen. When on high dpi the .300.Resx file is used.

@Yecats

This comment has been minimized.

Show comment
Hide comment
@Yecats

Yecats Apr 27, 2017

Contributor

@JoeErickson - Unfortunately, there's no way to track the current progress. Thanks for offering to be involved in the development process! I'll let you know once we have something that can be tested.

@juanjoseluisgarcia Thanks for the suggestion! I've passed this along to the team so that we can investigate.

Contributor

Yecats commented Apr 27, 2017

@JoeErickson - Unfortunately, there's no way to track the current progress. Thanks for offering to be involved in the development process! I'll let you know once we have something that can be tested.

@juanjoseluisgarcia Thanks for the suggestion! I've passed this along to the team so that we can investigate.

@tabaguley

This comment has been minimized.

Show comment
Hide comment
@tabaguley

tabaguley Apr 28, 2017

In performing an initial test of HDPI, I have found that controls anchored to something other than Top-Left will displace radically when moving between two differently scaled monitors. I tried this with a ListView, anchored Top-Left-Bottom-Right, and a button anchored Bottom-Right. After a couple passes moving back-and-forth between a monitor at 100% scaling and another at 200%, both of those controls either over-lapped other controls or where completely off the form. So obviously, control positioning & anchoring needs to be addressed. Thanks.

Looking forward to seeing this feature fully tested & built out!!

In performing an initial test of HDPI, I have found that controls anchored to something other than Top-Left will displace radically when moving between two differently scaled monitors. I tried this with a ListView, anchored Top-Left-Bottom-Right, and a button anchored Bottom-Right. After a couple passes moving back-and-forth between a monitor at 100% scaling and another at 200%, both of those controls either over-lapped other controls or where completely off the form. So obviously, control positioning & anchoring needs to be addressed. Thanks.

Looking forward to seeing this feature fully tested & built out!!

@jonreis

This comment has been minimized.

Show comment
Hide comment
@jonreis

jonreis May 15, 2017

My understanding is that if I would like to take advantage of the High DPI improvements, I need to add the following section to my app.config file: <System.Windows.Forms.ApplicationConfigurationSection> as well as adding <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" /> to the app.manifest file. Adding the new section to the app.config file requires the application to compile against .NET 4.7, otherwise, the user gets a "Configurationerror.sException: Unrecognized configuration section System.Windows.Forms.ApplicationConfigurationSection".

Therefore, it seems like I cannot take advantage of the High DPI improvements until all of my customers have upgraded to .NET 4.7. Is this correct? If so, this is bad because I cannot force my customers to upgrade, and I have to release 2 different versions of my product, one for .NET 4.7, and one for prior versions.

If previous versions of .NET, it was possible to opt-in to the new support without all these extra conditions. If the OS supported the new features and the application opted in, the application would get them, otherwise they wouldn't.

Can you please add a way of opting into High DPI support in code and without having to recompile the application against .NET 4.7?

jonreis commented May 15, 2017

My understanding is that if I would like to take advantage of the High DPI improvements, I need to add the following section to my app.config file: <System.Windows.Forms.ApplicationConfigurationSection> as well as adding <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" /> to the app.manifest file. Adding the new section to the app.config file requires the application to compile against .NET 4.7, otherwise, the user gets a "Configurationerror.sException: Unrecognized configuration section System.Windows.Forms.ApplicationConfigurationSection".

Therefore, it seems like I cannot take advantage of the High DPI improvements until all of my customers have upgraded to .NET 4.7. Is this correct? If so, this is bad because I cannot force my customers to upgrade, and I have to release 2 different versions of my product, one for .NET 4.7, and one for prior versions.

If previous versions of .NET, it was possible to opt-in to the new support without all these extra conditions. If the OS supported the new features and the application opted in, the application would get them, otherwise they wouldn't.

Can you please add a way of opting into High DPI support in code and without having to recompile the application against .NET 4.7?

@gluck

This comment has been minimized.

Show comment
Hide comment
@gluck

gluck Jun 6, 2017

Hi

Running our desktop Winforms app (as-is) on Windows 10 Creators takes a huge performance hit on various scenarios involving Screen class (right click menus and window moving at least).
Reason is that the previously [ThreadStatic] WindowsGraphicsCacheManager.measurementGraphics exists no longer, and is now replaced by a field in Screen class, allocated for each instance.
It means that every call to Screen.From* will run/allocate it.

Unfortunately it involves creating collectable (as-in by GC, not-by-code) GDI handles (CreateCompatibleDC), and such handles (if allocated/reclaimed in large numbers, above the HandleCollector hardcoded thresholds) will trigger many GC.Collect/Thread.Sleep in the UI thread.
Because Screen is a rather short-lived object, it's usually called in many places, many times.

Workarounds seem to exist (e.g. for ToolStripMenus, you need to make sure any modification of the menu/submenus is done with the layout suspended), but it's a huge impact across the application (menus take 2+ seconds to open versus instantaneous in earlier runtime versions).

Let me know if there's any flaw in the analysis, I may have missed something.

gluck commented Jun 6, 2017

Hi

Running our desktop Winforms app (as-is) on Windows 10 Creators takes a huge performance hit on various scenarios involving Screen class (right click menus and window moving at least).
Reason is that the previously [ThreadStatic] WindowsGraphicsCacheManager.measurementGraphics exists no longer, and is now replaced by a field in Screen class, allocated for each instance.
It means that every call to Screen.From* will run/allocate it.

Unfortunately it involves creating collectable (as-in by GC, not-by-code) GDI handles (CreateCompatibleDC), and such handles (if allocated/reclaimed in large numbers, above the HandleCollector hardcoded thresholds) will trigger many GC.Collect/Thread.Sleep in the UI thread.
Because Screen is a rather short-lived object, it's usually called in many places, many times.

Workarounds seem to exist (e.g. for ToolStripMenus, you need to make sure any modification of the menu/submenus is done with the layout suspended), but it's a huge impact across the application (menus take 2+ seconds to open versus instantaneous in earlier runtime versions).

Let me know if there's any flaw in the analysis, I may have missed something.

@apwr

This comment has been minimized.

Show comment
Hide comment
@apwr

apwr Jun 30, 2017

@gluck I think your issue is the same as this one:
#397

apwr commented Jun 30, 2017

@gluck I think your issue is the same as this one:
#397

@gluck

This comment has been minimized.

Show comment
Hide comment
@gluck

gluck Jun 30, 2017

Indeed, thanks @apwr !

gluck commented Jun 30, 2017

Indeed, thanks @apwr !

@Petermarcu

This comment has been minimized.

Show comment
Hide comment
@Petermarcu

Petermarcu Nov 8, 2017

Member

This issue has run its course. Thanks for all the feedback!

Member

Petermarcu commented Nov 8, 2017

This issue has run its course. Thanks for all the feedback!

@Petermarcu Petermarcu closed this Nov 8, 2017

@drewnoakes drewnoakes referenced this issue in gitextensions/gitextensions Jun 7, 2018

Closed

.NET 4.7.2 upgrade #5039

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment