WPF in .NET 4.6

| by Jonathan Allen Follow 576 Followers on Apr 22, 2015. Estimated reading time: 2 minutes |

Despite rumors to the contrary, WPF development at Microsoft isn’t dead. There are four major areas of investment for WPF in .NET 4.6 and beyond:

  • Performance
  • DirectX Integration
  • Supporting Modern Hardware
  • Tooling

Before we get into that, we should first talk about support. Microsoft has been accused on numerous occasions of aggressively closing bug reports for WPF and other libraries without properly investigating them, let alone fixing them. As part of the 4.6 roadmap, Microsoft will be reopening any bug logged in Connect with 10 or more votes. While this doesn’t make up for past mistakes, it at least shows that they are starting to take community feedback seriously.

Long term, WPF in .NET 4.5.2 is guaranteed to be supported at least until 2024. This is based on the fact that .NET, and thus WPF, is considered to be an OS component an thus inherits the OS support lifecycle.

Touch Support

Touch support improvements focused primarily on reliability and performance, especially while the UI thread is busy. Multi-touch events should also be more reliably reported.

Scrolling and Virtualization

A cornerstone feature of WPF is its ability to virtualize controls in a list. In theory, this allows for lists that contain in excess of 10,000 items. In practice, virtualization can fail for a number of reasons. One of these reasons is hangs due to excessive layout cycles, which WPF 4.6 intends to resolve.

Transparent Child Windows

The ability to mark child windows as transparent was added in Windows 8. This behavior has likewise been exposed to WPF. It requires indicating that Windows 8 features are in use via a manifest file. If the application is run on a Windows 7 machine, no exception will be thrown but the child window will not be transparent.

High DPI Issues

WPF can now understand cursor files that support multiple resolutions. When loading a cursor file, you need to pass in ‘true’ for the new scale with DPI parameter for this to take effect. Previously you could work around this limitation by manually detecting the DPI and loading the correct cursor image.

Another High DPI issue is the way backgrounds on controls such as the combo box are drawn. While technically incorrect at any DPI, the symptoms of this bug such as clipped borders don’t become visible until higher DPIs come into play.

Tomorrow we’ll talk about the long-term plans for WPF including WPF App Local.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you