Programming Life in the WPF – Part 6


At the end of the last section I tied off a discussion of the graphics rendering in AvalonLife with a look at its performance running a large model on a large grid. There is so much happening under the hood that I had sworn it would crawl when it came time to actually draw anything. And yet, the performance when I got it running was more than acceptible. This is interesting, but why is it notable or important? Nobody is actually going to program games in the WPF, are they? A few weeks ago I would have said “no.” Now… well, I’m not so sure. The framework is efficient and very well designed, and there is a whole layer of 2D and 3D animation support that hasn’t even been touched on here. I can see those facilities being used for some relatively low-velocity games, and if it turns out that there are good ways to interop WPF and Direct3D, such that you can use WPF and C# to script and drive the interface, and then overlay it on a rendered 3D scene, then things could get much more exciting. It’s the “overlay” part that is the problem now, as I understand it, but perhaps Microsoft will come up with a solution. Even if the graphics model works for games, there are others reasons to be wary about designing a game with thousands of on-screen objects the way this one is designed. For one thing, it eats gobs of memory. AvalonLife takes up something like 80 megs running a 100 x 100 model.

But forget about games for a moment. The easiest way to dismiss any new user-facing technology is to fault it’s performance. Windows Presentation Foundation is without a doubt a complete remaking of how Windows GUIs are developed. People who do thick-client application development on that platform won’t necessarily be eager to toss several years of Windows Forms experience to learn something new. If it didn’t perform well, it would be easy to ignore it and keep doing what you’re already doing. But it does perform well. In fact I think my little experiment, aside from being a lot of fun to do, demonstrates that it performs very well indeed. In the screenshot at the end of the last section I showed AvalonLife running a grid that required nearly 15,000 WPF objects to be instantiated and wired up to events. Most people who adopt WPF aren’t going to be creating that many objects. They’re going to be writing applications with more mainstream user interfaces, like text editors, and DVD burning utilities, and video players. The performance of AvalonLife indicates that you can expect very smooth operation from even complicated user interfaces implemented on this framework. If you’ve used Windows Vista you might already be expecting this. Its interface performs very well from a rendering and responsiveness perspective, and it is based on WPF. If you haven’t used it, you may now see a reason to give it a try.

If performance is not a disincentive, are there any other reasons not to adopt XAML and WPF for Windows application development? I think that if it has negatives, they lie in having to learn to manage XAML as an asset, and design carefully at the interface between markup and code. Let’s be honest: that interface has always been a pain, and although language development has progressed steadily over the last decade it is still a trivial task to produce spaghetti. There’s no question in my mind, having worked with XAML for a month on the AvalonLife project, that it is just the right way to describe a GUI. Once you have this capability it makes no sense to try to describe one in code again. I reviewed Borland’s Delphi environment (for Software Development Magazine) back in 1995, and I know what impressive feats they had to accomplish to tie a visual design environment to an expression of a hierarchy of object states in code. It’s been done since, in that company’s C++ Builder, and design interfaces for MFC and Forms classes. Other environments based on other languages had it even longer ago. But in none of these cases could the code be understood as an interface by a human, without the intercession of the binary interpreter. There is a CTP release of the Cider visual designer in the VS 2005 extensions for WPF, and it works pretty well, but I found that I didn’t even need to use it. Just as I often find it easiest to type HTML markup directly (as I am doing in order to write this), I find it easy to jump in and write XAML.

To avoid that spaghetti, though, it will be important to have some conventions for writing XAML, and to stick to them. One of the things that the framework envisions is designers using tools (like Microsoft Expressions) to create interfaces in XAML, which can then be passed on to programmers to be implemented. That has some interesting implications, because while you can fully describe the appearance of the UI in XAML, you cannot fully describe its behavior. If designers code XAML to layout specifications, working from wireframes, and developers code domain objects and data access, then at some point the layout is going to be wired up to the domain information with events and data binding. The code gets its fingers into the XAML. What will be of use is good modelling and diagramatic description of user interface events and data bindings, which along with adherence to proper naming conventions will allow designer and developer alike to understand how the GUI behaves in response to user input. That shared understanding will be critical.

Despite these potential hurdles, I think WPF, XAML, and .NET 3.0 are another huge leap forward in the art and science of software development. Whatever your normal view of Microsoft, you have to give them credit for really excellent thinking on the subject of languages, and how they are used to create programs. The CLR and MSIL probably represent the best compile- and run-time environment for implementing and executing software that has ever been developed. Visual Studio 2005 and C# are certainly contenders for the title of best code-time development environment. And now with XAML the language architects in Redmond have carried the vision one logical leap further, and handed us the ability to express high-performance, and high-quality, user interfaces in declarative markup, with all the power of the .NET 3.0 framework available to make the guts function. It’s pretty damn slick, and I think it is just this sort of progress that keeps developers coming back to Microsoft platforms. That’s a big part of what keeps the Windows operating system on top, and its a big part of what will make Windows Vista, the native home of WPF, attractive to both programmers and users.

Part 1 – The Game of Life
Part 2 – AvalonLife’s Architecture
Part 3 – XAML and the User Interface
Part 4 – Resources and Styles
Part 5 – Drawing the Grid
Part 6 – Conclusion

AvalonLife Program
AvalonLife Program with Source

Leave a Reply

Your email address will not be published. Required fields are marked *