This is Floyd Marinescu at the Q-CON Conference here with Ian Griffiths. Ian, can you tell us a bit about yourself?

I am a freelance consultant, but I also do training for the Pluralsight, so my consulting work is mainly focusing on graphical technologies and a particular WPF.

Should .NET developers be deploying WPF yet?

This depends entirely on what they are doing, because the truth today with WPF is that for certain kind of applications is just not ready yet. This was a deliberate choice of Microsoft, it's a version 1 technology, so inevitably they are not going to be able to get every single feature they wanted in, otherwise it would have shipped even later than it did. They decided to address certain scenarios and then aim to the ones that WPF had a natural advantage on, so in particular applications that can take advantage of the integrated support for different kinds of media and animation. Taking an example, I worked for an application earlier this year, for a well known broadcasting outfit in Britain who needed the ability to present video with overlaid information that was retrieved the database. So this support for data binding and video playback and transparency and text handling meant that it was a no-brainer that WPF would be able that to work, in a way that would have taken yet 4 times than it would in other way, but the certainly applications of the less well mashed, so if you are building a business application like a data entry form or something then win those forms that give a better choice today, not because you can't build that sort of thing with WPF, you can but it is just that the tools support is a long way behind, a visual studio doesn't actually have proper supported WPF features yet.

If you want to do it today you have to download a CTP, either the plug-in for Visual 2005 which they are not going to develop any further as far as I know, or you have to download the previews of Orcas which is the next version of Visual Studio, which is where the first supported features of WPF are going to appear, but that is not here yet an that is going to be a while off, so you have to live without a proper developer or a design environment today and that is a lot to give up. It's a bit like going back to writing RC files by hand so that you can do it and some people even advocate that and to be honest it's an awful lot of work. So the two questions are: 1. "Do you have a lot to benefit from the things WPF offers that other technologies don't?" If you do then probably go with it but be aware you are going to have a lot of pain.

The second question to ask is: "If you don't have an obvious benefit from WPF are you making a long term strategic decision about the platform you are going to be running on for the next 5 years or so because if you are today is a little early to move to WPF, but 5 years from now it's probably the right place to be certainly compared to Winforms, not that Winforms are going anywhere but it's probably had the majority of the development it is going to see. Now Winforms take second place as far as new features are concerned. So for a strategic long term play now may be the time for WPF although that's not even clear-cut. If the answer to both questions is "No" then I would say it probably a bit earlier and I'll wait until the Visual Studio 2008 tools are properly available.

And even when the tools become available what's in it for the WinForms developer to start using for vector graphics and all the stuff that WPF provides?

The first thing to say is that you don't have to use the flashy graphics, in fact that is not the only benefit WPF has to offer, in fact pretty much the topic of my talk this week at Q-CON has been the aspects of WPF that are interesting to developers that are not that impressive to look at which tend not to get coverage and demos. It's a little unfortunate problem because some things in WPF demo so well, you can use fabulous looking stuff that everyone is impressed about. People tend to overlook the less glamorous aspects of it even though they can be really powerful. For example data binding is a kind prosaic, right? A new idea, but WPF's data binding has some facilities that make it far more powerful for things that have come before it.

For example you often don't necessarily need to have a data grid to do the kinds of things that people would have gone out and bought a Grid for before. You can just use the data templating services to put eligible features into a list box, for example, and that is not particularly visually impressive but it's useful and easy and it makes it very powerful. So in fact I know some people who are using WPF through interop. They're hosting WPF inside of Winform applications using the interop services and doing that just so they can get the data binding services WPF has to offer. So that's one useful benefit straight away.

There are also performance benefits that WPF is designed from scratch to be used in managed code and the interop boundaries, where you get the transitions between the unmanaged world and the managed world, have been very carefully placed to get the maximum performance, whereas Winforms didn't really have that. Winforms sort of had to make those decisions based on the architecture that was already there and suffers as you increase the number of controls on a form quite badly, so in WPF you can actually have literally thousands of elements in your visual tree or if you drop down to the slightly lower level of just graphical elements rather than interactive things these shapes and these brushes you can have thousands of things on the screen and that is kind of hard to do with Winforms. So the scalability is a benefit and to be honest it's a nicer API.

When I have to go back to those Winforms now it just strikes me as hard work, the factoring is better in WPF, they have got a better separation of concerns, things like the distinction between controls and their content is better made, it's not just like a text label, as a feature; they have got this ideal of the thing inside of the control can be whatever you wanted to be, it might be data, it might be content, so that sort of thing makes certain sorts of work much easier in Winforms. You would have to be writing in your own custom rendering code to make that happen. So essentially life is easier, apart from the lack of the tools, that is the one thing that is harder, but if you are coding it's just a better designed .NET API because it was designed to be .NET from day one.

What are some of the performance recommendations for using WPF?

The big thing with WPF that will tend to get you with performance if you have issues is memory consumption. In particular it's the number of elements in what we call the "visual tree". So in WPF there is this concept of a "visual tree" which is simply a tree of .NET objects that represent things you can see, objects derived from the visual base class. Now if you do every little thing on the screen with a single object in the visual tree the number start up very quickly, particularly if you are using the templating and data binding services, they can actually generate UI elements for you and it is very easy to find yourself with an order managing more than you thought you had because of all the stuff WPF stuff has done for you under the covers. So in this application I was working on earlier this year, we ended up with 6000 or 7000 items in the tree without really trying. Mainly because we were doing nice fancy search results and when the big searches came back it would just completely blow away a number of items in the tree. So the trick to reducing it is not to throw away detail, you don't have to do that.

You just need to approach things in a different fashion, so rather than relying on the generative services that WPF offers to generate lots of things, consider using an aggregation technique where you have one item in the visual tree containing more complex visuals, because you can have a single element in the tree hosting thousands of actual shapes and geometries and so on. So in this application we worked on, we had a little ratings control, with sort of 5 stars on a row. When we started out that actually had about 30 elements in it because that was the stars that would layout things around the stars and there was one of those on every single feature in a certain list and that really cranked up our numbers. So to fix that we just had one rectangle and gave it a pattern of repeating stars and that instantly had a noticeable effect, the application became snappier. So that is really the single biggest thing: keep the number of items as a new visual tree down and consider moving from a sort of element heavy approach to an approach where you might grant more detail into this sort of drawing elements.

Also on topic of performance, is it a wise choice to scale by moving drawing to the GPU as hardware moves to parallelism?

The thing to understand is that while computers are getting more and more computational power, it's not necessarily the computation that you require to do heavy EG graphics work. What actually really kills you on a CPU is the sheer volume of data that you have to push around. The things that a graphics card is particularly good at is dealing with large volumes of pixels. They can fill the entire screen with pixels in a fraction of the time that the CPU can because that is what their specialty is, they have these dedicated graphics buses designed for speed, designed for sequential filling at high rate. Whereas the CPU has 2 problems to contend with: first, the interface to the memory it has to talk to is just not as fast as a graphics systems can be, but worse than that if it generates all the graphics, it will be doing that in main memory.

Then it has to get that onto the graphics card and even with the advances in bus technology with all the AGP stuff and now we have got PCI Express, even though those have made leaps and bounds forward they are still, in no way, close to what the graphics card can do internally. To the extent that when Microsoft was doing power management tests they thought they were going to find that if they switched off the GPU, which is a big hog of resources, they thought what they were going to find it would be better to render stuff in software when people were running off battery to get better battery life. But they actually found by shoveling work onto the GPU they could switch it on, run the rendering, then switch it off again in far less time than the CPU could copy the bits onto the graphics card. Power consumption went down. So it's not the case that just because you have the grant of the CPU that it is going to help you, if it's in the wrong place, you need it localized because of the shared volume of data. That's less of an issue for the shared memory architectures like Intel is going to do integrated graphics chip sets. They obviously have better communication because there is only one bunch of memory, but for any discreet graphics chips this is definitely a big deal. So the GPU is important.

What's the story around WPF in the browser?

There are couples of angles on this story. The simplest answer to this is that there is a way you can deploy an ordinary WPF application, called an XBAP. XBAP stands for XAML Browser Application. Either that or no one was using that four letter abbreviation, so they decided to make it stand for something elevatory. XBAP is the extension and it actually uses the click-once technology. Under the covers it is the same thing you can use to play Winform applications over the web, but the application is hosted inside of a browser frame and is always subject to a non-negotiable security sand box. So it's sort of similar to the Java applet model in that you have to conform to the security rules. You are not allowed to do stuff like touch the local hard disk, but you do get to run in the browser, you do get to have access to the full set of rendering capabilities that WPF has, although you can't open top level windows because that is a secure operation. So that works, but of course that does require you to have the .NET 3.0 client installed on the end-user machine, so that is not going to work well for the Apple-Mac users, or the Linux users and right now there is no support for Firefox, even on Windows where the .NET 3.0 may already be installed.

No one has done the work, as far as I am aware, to integrate the XBAP browser hosting into Firefox. That will probably come, as it seems like an obvious project for someone to do, but it is not available right now. So that is obviously applicable to a limited number of scenarios. There is a completely different technology, even with a very similar name called: WPF/E. At least that is what its tech code name is right now and WPF/E does run other platforms. There is a plug-in for Firefox, it also runs on the Apple-Mac, both on PowerPC and Intel based Macs, and will plug into Safari. This implements a very small subset of the capabilities of WPF. It is essentially just the graphical capabilities, so, all of the same geometry support, some of the text support, and animation support. What they don't have is the 3D support, largely because they also want to target handheld devices like phones and there isn't often enough CPU power to do that, so with version 1, that's not on the list. So, that does offer a much broader range of target platforms but you loose a great deal.

You don't have any of the developer oriented features like styling, like templates, you don't even have controls, you have to handle the low level clicks mouse button up and down and write Javascript to actually enable the control to be able to do something. And of course there is no .NET framework because it is not Windows in there right now and there is not a version of .NET available for these other platforms. There is one in the pipeline, but it's not there today. So, it's essentially the WPF drawing primitives controlled through Javascript and that is available to anyone who downloads and installs the plug-in. But of course, it's not full WPF. The thing that people often ask for, which does not exist, is some magic switch you can throw that will take your full blown desktop client and magically turn it into something that will run in a web browser. That just doesn't exist and it is difficult to see how it could exist without just writing everything to a lowest common denominator.

WPF/E, does it really have a chance?

It is very difficult to say because if you look at the obvious competitor, Flash would be the obvious one there because it's a cross platform browser based plug-in and that lets you do fancy graphics and they have got a huge lead in terms of market penetration.

Flash is almost everywhere and you can just pretty much assume that is available to your own website and WPF/E today is pretty much nowhere. Right now the tool support is also pretty much not there so, they are a long way behind. Then again, Microsoft has a good record of catching up. So, possibly, the real question is: "Will Flash drop the ball at some point in the future enabling Microsoft to sort of muscle in on that territory?" So, I think it is too early to call right now but I would be surprised if the early adoption was particularly fast. I think it will take them a few versions before they start to have both the technology and the tool chain that looks sufficiently compelling to draw people away from Flash. But they have a good record with drawing developers on board in the long run, so I wouldn't rule that out either. I just think it is a long haul.

WPF/E versus Microsoft based AJAX applications, how does one choose?

There are some situations where it is very clear-cut in favor of the AJAX approach. So, if you have to ship now then probably the AJAX approach because right now as I'm speaking in the WPF/E plug-in is still a CTP, but once it ships, AJAX is going to have a broader reach, so if you don't think you can convince people to download a plug-in then AJAX definitely has some plusses there. If you are thinking about corporate environments, they may have the ability to push the thing out, on the other hand machines might be locked down. So, if you want to reach people and you don't necessarily have control of their desktops, then AJAX is a path of less resistance because everything they have is already there. Whereas installing yet another plug-in you are going to have a bunch of hurdles to jump through and for some people that is not even an option.

Particularly now that Vista is getting a bit more twitchy about telling you about dangerous things happening. If you get some scary message saying: "Are you sure you want to install this?" people are saying: "I don't want to rap off the rule.". Whereas AJAX just works, as soon as you go there. As for when it might swing in the other direction, while the biggest weakness AJAX has right now is doing graphical content. If you want to do nice looking visuals without just relying on bitmaps, then Ajax is weak; sometimes bitmaps are good enough because you just draw what you want and then show that, but if you want to have things moving around, if you want to have the graphical features being more than just a static bunch of pixels buried in the depth of the bitmap then to be real objects you can't have them as a pre-rendered image and for that WPF/E definitely has more of an edge. In that situation it may not even be WPF/E versus AJAX, it might be AJAX with or without WPF/E because in practice WPF/E relies on the client-side Javascript to do most of the work. That is a small leap from there to a more AJAX kind of thing, that is probably going to be more of a continuum then either/or cases where WPF/E looks attractive.

Any other final words for .NET developers and WPF/E or WPF?

Obviously they should buy Chris Sells and my book on WPF. We are doing a second edition of the book for that which should be out by the time this airs of shortly after.

And what are your two favorite computer science books?

My two favorite computer science books; I would have to go far back as Tannenbaum on "Computer Networking", it is a pretty old book now but for me that was a huge deal because I spent the first few years of my professional life doing computer network, device drivers and without that book I probably wouldn't have got into that line and that was a lot of fun. The second book: Henessy and Patterson's "Comparative Computer Architecture Book: A quantitive approach." because I always loved know what was going on down at the lowest level. I did device driver kind of work and I did electronics before that and that just gave a huge amount of insight into what really goes on inside of CPUs and why they are built the way they are. That is one of the most memorable ones I have ever read.