News

Next Up for WinForms in .NET 6 Is High DPI Support

• By David Ramel
• 12/11/2020

While Microsoft and community developers have improved desktop dev tooling in .NET 5 and new open source implementations, the tech hasn't translated easily from the Windows-only .NET Framework, and catch-up efforts planned for next year's .NET 6 include high DPI support for one troublesome project, Windows Forms.

Microsoft yesterday (Dec. 10) updated the community on the efforts behind the WinForms runtime in the recently released .NET 5 and provided a peek into what's planned for the November 2021 debut of .NET 6, which is scheduled to include some one-size-fits-all unifying features that didn't make it into .NET 5.

Several of those missing features can be found in the desktop offerings, WinForms and Windows Presentation Foundation (WPF).

As far back as last year Microsoft decried the "huge technical challenge" of transferring WinForms from .NET Framework to its open source, cross-platform successor, .NET Core.

"For developers the .NET Core Windows Forms Designer (when we will release the GA version) will look and feel the same as the .NET Framework Windows Forms Designer," said Olia Gavrysh, program manager, .NET. "But for us it is a huge technical challenge to bring the designer to .NET Core because it requires the design surface that hosts the live .NET Core form to run outside the Visual Studio process. That means we need to re-architect the way the designer surface 'communicates' with Visual Studio."

Work has progressed since then, however, and Microsoft recently announced that Visual Basic in .NET 5 was ready to develop WinForms apps, with Visual Studio 16.8, which sports the Windows Forms Designer.

Furthermore, this week's update about what's new for the Windows Forms runtime in .NET 5.0 details:

• New TaskDialog control
• ListView enhancements
• FileDialog enhancement
• Performance improvements
• Accessibility improvements and fixes
• Visual Basic support

Speaking of performance improvements, Igor Velikorossov, software engineer, Windows Forms, said:

Windows Forms has always been known as a managed wrapper around the Win32 API set. As such, Windows Forms has always depended heavily on an interop layer to communicate with the unmanaged Windows components. The top priority from the early days of .NET Core has been the optimising of our interop layer, making structs blittable, explicitly opting for more efficient 'W'-functions, and using 'unsafe' code where possible. All these changes are what we call 'peanut butter changes,' in a sense that each of these are tiny and hardly observable, but over a lifetime of an application these changes add up to a substantial performance gains.

In .NET 5.0 we've lifted the bar higher and optimised several painting paths. Historically Windows Forms relied on GDI+ (and some GDI) for rendering operations. Whilst GDI+ is easier to use than GDI because it abstracts the device context (a structure with information about a particular display device, such as a monitor or a printer) via the Graphics object, it's also slow due to the additional overhead. In a number of situations where we deal with solid colours and brushes, we have opted to use GDI.

More graphics work is needed, though, to address lingering, pesky problems. As far back as last September, Microsoft's Kathleen Dollard noted "we're still settling on some issue around HighDPI" while announcing a .NET 5 release candidate.

This week, Velikorossov alluded further to those issues in looking at what's ahead for WinForms in next year's milestone release.

"We are aware that the current high DPI support is far from perfect, and this is something we are planning to improve in the .NET 6.0 timeframe," he said. "There are many aspects to what 'high DPI support' means, so we would love to learn more about what it means to you. If you have a specific concern that you'd like us to address, please leave a comment below or file an issue directly in dotnet/winforms."

The post also explains breaking changes and known issues in .NET 5, which for WinForms includes:

• ListView redraws when images are added to its ImageList. When adding a image to the ImageList, the entire contents of a ListView that is using that ImageList is redrawn. This causes it flicker and if there are enough items, it slows down the app. The issue is expected to be fixed in 5.0.2.
• If you assign a string that contains one or more '&' chars to a ToolStripStatusLabel, the string is displayed without '&' chars.
• It is impossible to specify an image for a ListViewGroup in the Designer using either TitleImageIndex or TitleImageKey properties.

Note that transferring desktop tech in general to cross-platform implementations has been tricky, as problems also occurred with the open source WPF project. Microsoft in September announced it was retooling the WPF open source effort after receiving negative feedback.

That feedback came in the form of a GitHub survey. "WPF was the main outlier for satisfaction," Microsoft said. "Drilling into the comments, the main concern was that PRs [pull requests] and issues were not being addressed by the maintainers and there was a lack of clarity on if and when they would be. Internally the WPF team was not sufficiently staffed and did not have the test infrastructure in place to be able to respond to the community contributions."

Microsoft is addressing those issues in multiple ways, the company said in a post that references a new WPF roadmap.

Back on the WinForms side of things, Velikorossov pointed to further work to be done besides the high DPI effort. "We plan to continue with 'peanut butter' optimisations, accessibility improvements, nullable reference types annotations, and general code improvements," he said.