One of the limiting factors in WPF development is the fact that it is a core component. Since it is shipped with .NET itself, and often the OS, the compatibility requirements are extremely high. Of course perfect backwards compatibility isn’t possible for such a large framework, but any risky change such as supporting newer versions of DirectX are very difficult to justify.
In WPF vNext, the plan is to offer an “App Local” version of WPF via NuGet. This is essentially the same distribution plan currently used by ASP.NET MVC. Key features include:
- Each application ships with its own version of WPF
- Similar, and often much better, performance characteristics
- Built on top of .NET Framework for Desktop, not necessarily .NET Core
- Highly compatible with the inbox version
Note that “highly compatible” doesn’t mean perfectly compatible. Since changes to WPF App Local are opt-in, Microsoft feels that it can be a little more relaxed when it comes to maintaining compatibility.
An example of one of their “mostly compatible” changes is the new default templates. On a fairly simple test form using WPF 4.5 they demonstrated that it contained 281 elements. By switching to WPF vNext assemblies that count dropped to 230 elements with no visible change.
This change was possible in part due to the new “Content Deferral” feature. This allows controls to lazily load their content. Sometimes that content will never be loaded; for example, the disabled visuals on a combo box that is never disabled.
Early tests with just built-in controls show a 10% improvement in startup and memory use in some cases. Higher performance improvements are expected when using this feature in application code. Microsoft’s internal studies showed that up to 40% of all elements created in application startup were never actually displayed.
Again, the reason that this isn’t being offered in WPF for .NET 4.6 is that there may be applications that are dependent on the current design of the visual tree. The hope is that since WPF vNext is opt-in via NuGet, any application that could be affected by this change will be tested accordingly.
DirectX Interopt
No details are available, but the gist of it is that Microsoft intends to offer “native DirectX 11 and 12 support” in WPF. More information is expected to be released at Build 2015.
Modern Styles and Touch
WPF is also supposed to offer support for Windows 10 styles and design guidelines. Again, details won’t be available until Build.
Open Source
Microsoft is not planning on open sourcing WPF at this time. However, they see WPF App Local as an important stepping-stone towards eventually offering the code as open source. Before they make that leap, they want to experiment with developing WPF in an open environment, meaning there will be a lot more interaction between Microsoft and developers between major releases.
In our third installment, we will be discussing tooling for WPF in Visual Studio and Blend 2015.