Today I'm excited to announce the public beta availability of a major new release of WPF. Since we shipped .NET Framework 3.5 late last year, the team has been hard at work at a new release that adds many supplemental features, fixes a good number of bugs, offers many performance optimizations, and includes a new streamlined installer for a subset profile of the .NET Framework optimized for client scenarios. This new release will ship as part of .NET Framework 3.5 Service Pack 1 later this summer; the beta release is an early preview of these enhancements. In this blog post, I want to provide a broad overview of the new features in this release, focusing on WPF.
Deployment
It's been interesting over the last year or two to see the balance between business and consumer applications developed using WPF. Our early expectation was that WPF would be used primarily for consumer software: the assumption was that animation, rich media, flow documents, 2D and 3D graphics etc. would be primarily of interest to those kinds of applications. In fact, it's been surprising how many enterprise applications have taken advantage of it: architectural patterns such as the data templating and binding model and the separation of UI from code have turned out to be even more compelling reasons to adopt WPF in many cases.
Although Windows Vista includes WPF out of the box, we recognize the need to provide a lightweight way to deploy the platform to desktops running Windows XP. If you're distributing a consumer application over the Internet, it's key to have a setup package that downloads and installs quickly, while providing the user good feedback on its progress. We've put the .NET Framework on a diet, and we've now got a solution for those kinds of applications. As well as the full .NET Framework, we now have a Client Profile that weighs in at about 25MB (roughly the same size as Acrobat Reader), installs in a couple of minutes, and provides a customizable install experience.
How did we reduce the size of the .NET Framework? We removed many assemblies that aren't typically used in client application scenarios (it would be an esoteric client application that needed ASP.NET to execute locally, for instance). The file list was selected over the past year through profiling of numerous client applications; at a high level, it includes the core CLR and base class libraries, WPF, Windows Forms and WCF. We also took advantage of some new compression technology to shrink the package considerably. You can still target the full .NET Framework, of course - this is just an additional option. And it's important to note that the actual shipping assemblies are identical in both the Client Profile and the .NET Framework as a whole.
In Visual Studio 2008 SP1 (also in beta today), you can target the Client Profile through a checkbox in the setup project template. You'll of course get a warning during the build process if you have this option set and your project has a dependency on assemblies missing from the Client Profile. When you compile the application, you will have the option to package the Client Profile installer and your application together into a seamless, unified installer for the best possible experience. We provide a tiny (~200KB) bootstrapper package that keeps to an absolute minimum the time between an end-user clicking the installer and seeing results. We even do a full ngen on the .NET Framework files asynchronously during the install process, so that nothing competing with the startup of your application when it runs for the first time. Despite all this, you should expect to see the full setup complete in a matter of just a few minutes.
How does an application know if it has enough of the .NET Framework to execute? I'm glad you asked that question! Only applications that have been compiled to target the Client Profile will contain the special manifest that indicates that they are supported on machines with just the subset. If you try and execute an application that isn't appropriately marked, the Client Profile will pop up a dialog that will help the end-user update to the full framework. It's also important to note that the Client Profile is fully compatible with ClickOnce.
For end-users who have opted into Windows Update, the .NET Framework Client Profile will be upgraded to the full .NET Framework through a background drizzle process so that applications that target the full framework will be able to take advantage of the increased number of people with WPF installed on their machines.
Lastly, shortly after Visual Studio 2008 SP1 ships, we'll be releasing an add-in that will provide developers with the ability to completely customize the look and feel Client Profile installer - changing background graphics, etc. We're also working with third-party installers such as InstallShield to build Client Profile support into their setup packaging technologies.
One other deployment feature unrelated to the Client Profile - we've slightly loosened up the policy for managed executables run from a network share to allow them to run with full trust. This is a popularly requested change, as Brad Abrams' informal poll testified.
Graphics
The shipping .NET Framework 3.5 included a few powerful enhancements to the WPF graphics engine; in particular, the UIElement3D and Viewport2DVisual3D classes that provide support for fully interactive 2D elements on 3D surfaces. We also made substantial performance improvements to layered windows and fixed occasional animation stuttering issues. But we've gone way further with this release, adding a number of heavily-requested graphics features.
As demonstrated at MIX08, 3.5 SP1 adds support for HLSL shaders with the ShaderEffect class (see image to the right), allowing an almost unlimited range of visual effects to be applied to WPF content. Shaders are implemented entirely on the GPU (if you have Pixel Shader 2.0 support in hardware), or otherwise with an efficient software implementation - this means you can add wild effects like flares, lensing, distortions or blurs without adding a significant burden to the CPU.
You can target the properties of a shader effect with data binding or animation, allowing for even richer effects, and because WPF is a fully-integrated platform, any controls on which a shader effect is applied remain fully interactive.
If that wasn't sufficient, by the final release of .NET 3.5 SP1, we'll have support for even deeper DirectX integration. Essentially, any Direct3D surface can be used as a brush for WPF content through the new D3DImage class, enabling you to overlay or blend Direct3D content interchangeably with WPF content. You can use multiple D3DImage classes simultaneously, and because they are still rendered by DirectX, there is no major performance impact. You can even alpha-blend Direct3D content. If that wasn't enough, you can even take a Direct3D surface and apply it as a texture within a WPF 3D scene - mind-blowing! More information on these features is available at Greg Schechter's blog.
We've got a vastly improved WriteableBitmap class that enables efficient image manipulation. WriteableBitmap provides a bitmap image that is mapped to system memory, allowing you to change the contents and have it automatically render to the screen (taking advantage of the retained mode model in WPF). The original implementation of this class allocated a new bitmap with every frame update, making it pretty slow for most scenarios. The new replacement is fast, synchronized with UI changes and has constant memory usage, enabling tons of new scenarios in WPF - for instance, paint programs, fractal renderers, and software webcam output.
We've made some minor granularity improvements to the tiering APIs, for instance, enabling you to verify whether pixel shaders are supported in hardware. We've added nearest neighbor image sampling as a bitmap scaling mode. Last, but not least, we've finally fixed the most common bitmap effects in WPF - no longer are blur and drop shadow software-rendered: if you use the new blur and drop shadow API introduced in SP1, they'll be fully accelerated using the GPU. The legacy blur and drop shadow APIs have also been hardware-accelerated, providing immediate, huge improvements to performance for applications which make use of those capabilities.
Performance
As Ian Ellison-Taylor, the General Manager for WPF, is fond of saying, we're never done with performance. As with any high-end graphics platform, there are always optimizations that can be made. In this release, we've made major strides forward with performance and memory usage of WPF applications across the board. You'll notice these improvements regardless of whether you're targeting WPF 3.5 SP1 or an older version.
"Cold" startup of an application is one area where people are particularly sensitive to performance. There's a lot to be done at this point in time: assemblies need to be read in from disk, their manifests need to be checked for strong name verification, and any dependencies need to be loaded and checked also. As an application author, you can have a substantial impact on the startup of your application by being sensitive to this: you should load only what you need to display the initial screen and delay the load of other assemblies until they're needed. If you need Windows Forms to display a couple of forms buried within your application, don't put a dependency in the executable that's first loaded - it'll add a couple of seconds to your application startup. We've gone through the WPF assemblies and done a lot of optimization work to ensure that we get your first pixels on-screen as quickly as possible: by RTM, we think cold startup will be improved by up to 45% depending on application size and scenario. In general, the bigger the application, the more gain you'll see.
For XBAPs, we've switched to HTML for the initial loading screen, so that you immediately see progress when you click on an XBAP rather than being greeted with a rather confusing blank browser page for the first couple of seconds. There are also some additional cold-start improvements on top of those mentioned above for XBAP scenarios which give an additional 10% boost.
By RTM, we'll also have a "splash screen" support in Visual Studio 2008 SP1 to minimize the work in building applications that display an initial screen immediately, having a big impact on the perception of an application's responsiveness and reducing the risk of an end-user accidentally firing up two instances. You can either designate an image as a splash screen by marking a bitmap resource with a build action of SplashScreen, or supply your own fully customizable class based on our template that is loaded prior to the Application object during startup.
It's not just cold-start scenarios where we've been hard at work optimizing WPF. We now have container recycling for controls based on the VirtualizingStackPanel class (such as ListBox, ListView and TreeView). This is an opt-in feature (you have to set the VirtualizationMode attached property to enable it) due to some subtle semantic changes to these controls' behavior, but it can provide up to a 40% scroll performance improvement by reusing the UI elements that go out of view during scrolling wherever possible. We also now offer deferred scrolling as an option (similar to the way the Outlook inbox scrollbar works).
There are lots of other control virtualization optimizations too: TreeView now offers virtualization (perfect for an Explorer-like scenario), and columns can now be virtualized, making it much easier to build an efficient DataGrid control. And we've identified and fixed a few other performance "cliffs": improving some text rendering and frequent z-order manipulation issues.
New Controls
It's been a long time in coming, but we're finally adding the much-requested DataGrid control to WPF. This will ship out-of-band at first, just after we release 3.5 SP1; it will take advantage of the various virtualizing optimizations mentioned above so it should be relatively efficient, and of course, like all WPF controls, it will be possible to completely change the look and feel of the control through templates. We made a number of API enhancements to better support the DataGrid scenario: multi-selectors, null value auto-conversion, transactional item editing, alternating row support, item-level validation - and of course, all these are available to third-parties to improve their own high-end data grid controls.
Another oft-requested control is the Office Ribbon, and I'm sure you'll be pleased to know that we're also shipping an implementation of that control, also out-of-band, before the end of the year. The ribbon will be fully implemented in WPF, will be compliant with the UI design guidelines and have an intuitive collection-based API.
The third control does ship in-box with .NET Framework 3.5 SP1, and is a richly-functional WebBrowser control. Since the initial release, WPF has enabled web content to be displayed via the Frame element, but that had a number of limitations: you couldn't interact with the content of the frame programmatically, HTML content could only be hosted from a URL (not from an in-memory stream or string), you couldn't navigate programmatically through the history, and you couldn't interact with any JavaScript on the page. The WebBrowser control offers all those capabilities, enabling much more seamless interoperability between WPF and HTML content. It also provides a great way for WPF to host Silverlight content - just point it at the Silverlight .XAP file. One other nice touch: it supports partial-trust mode for use within XBAPs, enabling an XBAP to include an inline frame of HTML content that can be interacted with.
Other Enhancements
There's a number of other small but useful enhancements in this release that don't really fit under any of the above categories. We now support string formatting for data-bound text: this saves you having to write a class that implements IValueConverter just to do something as simple as formatting a number. We've done some work to both simplify and deepen support for LINQ to XML and LINQ to DataSet for data bound members. Lastly, we've extended our Firefox browser support beyond the XBAP capability in 3.5 by adding native support for ClickOnce (.application files).
The WPF designer in Visual Studio 2008 SP1 has also undergone a major overhaul. It's faster, for starters, and we've done a lot of work to support some of the more esoteric XAML edge cases that previously caused the editor problems. There's now an event tab in the properties tool-window, which delivers parity with Windows Forms for creating and viewing event handlers from the designer. One feature that I know will be particularly appreciated by a few folk who've harangued me over the past few months in our labs is support for XAML refactoring - something that was previously a rather painstaking and menial task. Finally, there's support for BAML runtime debugging, enabling you to catch errors that would otherwise be hard to pin down.
Conclusion
It may be a slightly awkward name, but .NET Framework 3.5 SP1 represents a major new revision of WPF that brings it squarely into the prime-time. I genuinely believe we've nailed all the most common criticisms of WPF as a desktop platform with this release: a much better deployment story, some amazing new graphics capabilities, across-the-board performance improvements, the three most commonly-requested controls, and an improved editor experience. When you add all this up together, you can see why this servicing release is such a significant step forward for WPF - it opens up new territory and shows the growing maturity of our strategic next-generation UI platform for Windows.
Right now, SP1 is a beta release; we plan to ship the final version later this summer. As with any beta release, there are always a bunch of caveats relating to quality, and I really want to emphasize those a little more strongly this time round. I do not recommend installing this beta release on your main development machine. Due to some complex build timing issues, this release is incompatible with Silverlight 2 Beta 1; it will, however be compatible with Beta 2 when it ships in a few weeks' time. There's also a glitch we discovered in late testing that can cause Blend to crash; a hotfix is available to the 2.5 preview release that fixes this, and we'll of course have a full solution in place prior to the final release of SP1. Lastly, if you're running Windows Vista, you should install Vista Service Pack 1 prior to installing Visual Studio 2008 SP1 Beta. Hey - if this was done, we'd ship it - that's why we call it a "beta"!
One last thing - although I've majored on the improvements to WPF itself, this service pack also contains enhancements to ASP.NET, ADO.NET, WCF and Team Foundation Server. For more details on these broader changes, Scott Guthrie's blog provides the best overview.
So where can you go to find out more about this release? If this blog post isn't enough, you should check out the "week of WPF" that starts today on Channel 9. For seven days in a row, we'll post a series of interviews with the core WPF team, talking and demonstrating the new enhancements in this release. Adam Kinney and I had a lot of fun filming these, and I think you'll enjoy them. In the first interview, I sit down for a chat with Ian Ellison-Taylor and Kevin Gjerstad about the philosophy behind this release and the long-term direction for WPF. Check it out!
