Comparing WPF on Windows Vista v. Windows XP

Comparing WPF on Windows Vista v. Windows XP

Rate This
  • Comments 21

A question I'm often asked is, "what's different about WPF in Windows Vista compared to the version that ships for Windows XP?" In the interests of transparency (which is what blogs are for, right?) I thought I'd address this here.

I think it’s important to start by noting that the goal of adding Windows XP support was to allow people to write WPF code without worrying whether some things would only run on Windows Vista. There aren’t a whole swathe of features that are set aside as Vista-exclusive, and that’s by design. At PDC 2003 when we announced WPF (then known by the codename of "Avalon"), almost every breakout session concluded with questions from developers who wanted to know how much of what they'd just seen would be available on Windows XP. Based on the strong feedback we heard at that conference, we backported WPF to Windows XP so that applications written using the technology could be deployed broadly even before Windows Vista reached critical mass.

Of course, Windows Vista will be a natural way many end-users get hold of WPF applications, purely because .NET Framework 3.0 is installed by default on that platform. For Windows XP, .NET Framework 3.0 is an optional download from Windows Update or a bootstrapped install when an IE 7 user first visits a WPF XBAP application. It's a small thing, but having it installed and enabled by default makes a huge difference to how easy it is for people to deploy applications based on WPF, particularly in a locked-down, non-admin environment.

However, there are several optimizations made on Windows Vista that make it a worthy upgrade if you're planning on extensive use of WPF:

  • With DWM and a WDDM-class display driver, video RAM is virtualized so you don’t have to worry about WPF being forced into a software rendering mode because it’s run out of headroom;
  • 3D anti-aliasing is available on Windows Vista with a WDDM driver;
  • There’s work done to integrate with other parts of the platform that take advantage of the MIL, so for example the Magnifier accessibility tool in Windows Vista scales up WPF applications using vectors rather than bitmaps;
  • WPF animations on Windows Vista should be smooth and tear free if the DWM is enabled;
  • The tablet PC APIs expose a few minor Windows Vista-specific features relating to gesture support.
  • When remoting between two machines running Windows Vista and DWM, the client-side rendering of a WPF app will be hardware accelerated. No hardware acceleration occurs if one or more of the machines is running Windows XP; bitmap remoting will be used. The performance difference can quite significant depending on the visual complexity/use of animations in the app.

That said, it's important to note that the codebase is identical: we don't build a separate Windows XP v. Windows Vista edition. Until later builds of Windows Vista when we switched to the final staged layout for faster installation, it was possible to find the dotnetfx3.exe self-extracting archive in a folder called sysmsicache. In fact, I used to use this trick often myself to ensure that two side-by-side machines running different versions of Windows had the identical bits installed.

Of course, a “designed for Windows Vista” application could include other Vista-specific features: everything from new Vista shell capabilities like task dialogs and common file dialogs to peer-to-peer, search integration, sidebar, power management etc. If you use one of these Windows Vista features, your application should gracefully degrade for Windows XP as appropriate.

Hope this is useful!

  • Thanks, that was useful.  

    Does the same hold true for Windows 2003?

  • Eric, everything listed above is true about Windows XP and Windows Server 2003. I've got a vague recollection of some small thing about layered windows in Windows Server 2003 working better than in Windows XP due to a bugfix between the two releases, but that might have just been during the beta cycle. Most of the Windows Vista benefits have to do with the new display architecture, with the DWM and the new Windows Vista display driver model enabling certain optimizations over the older release.

    Hope this helps,

    Tim

  • So, if I understand this correctly, hardware acceleration in WPF is only available on Windows Vista, not Windows XP.

    Are there specific operations that are hardware accelerated vs. others that are not?

    Specifically, can you tell me which (if any) of the following methods are hardware accelerated?

    1. .NET Framework 2.0 on WinXP -  Graphics.DrawRectangle(...)

    2. .NET Framework 2.0 on Vista - Graphics.DrawRectangle(...)

    3. WPF on WinXP - DrawingContext.DrawRectangle(...)

    4. WPF on Vista - DrawingContext.DrawRectangle(...)

    Is there a difference between DrawRectangle and DrawLine in terms of hardware acceleration?

    Thanks for any clarification.

    Boris

  • Ping back from samiqbits.blogspot.com

    A question that should have gone around people's head already (it has for me and my team for a while) is how different the application performance between WPF-based applications running under Windows XP / 2K3 from those running in Windows Vista, is...

  • Boris, actually that's not correct - apologies if the entry misled you in that direction somehow. WPF is hardware accelerated on both Windows Vista and Windows XP for machines that have the appropriate GPU (that is, DirectX 9.0 and Pixel Shader 2.0 are supported in hardware). The majority of desktop and notebook machines sold over the last couple of years match this spec, and even entry-level machines these days support this comfortably. For any other machine, scenes are rendered using a software rasterizer that is identical in features but just a little slower. (For completeness, some machine configurations may fall back to software rendering for other reasons, such as a battery saving notebook power mode.)

    Outside of the likes of DirectX and OpenGL, WPF is the only platform that takes advantage of 3D hardware acceleration on Windows. GDI+ is still 2D whether you run it on Windows XP or Windows Vista. So the answer to your last question is that 3 and 4 offload the rendering to the GPU, 1 and 2 don't. A video card specialist (which I'm not) might take issue with suggesting that there's no hardware acceleration occurring for 2D - no doubt nVidia, ATI and Intel do work in their GPUs to optimize 2D graphics processing - but when we talk about WPF we're talking about offloading the whole rendering process to a DirectX class rasterizer. Hope that makes sense...

    Take care, Tim

  • Thanks!

  • Hi Tim,

    A question that is on my mind for sometime is about windows vista performance. Vista is my development platform since 5744. I've done some experiences with glass and wpf and I noticed that if you extend glass and use transparent objects in the WPF window you can see through the window, this means that the window is a PerPixelAlpha window, does this have any performance implication? Is there any way to improve this? It seems pretty obvious to me it is more performance intensive to draw transparent objects in a transparent background than in a opaque background. I can give you more details on this if you need.

    Thanks

    Bruno Silva

  • Bruno, yes - this can be significantly slower depending on the size of the region. As you suggest, there's more work to be done here than would otherwise be the case. Tim

  • Hi Tim,

    How exactly is Vista (DX?) serializing/deserializing 3D information for remoting purposes?

  • Not to take this off-topic, but Graphics.DrawRectangle is in fact completely unaccelerated. Although as Tim says most graphics cards will contain hardware functions for 2D processing (this has been around for a long time; back in the Windows 3.x days these cards were known as "Windows accelerator cards" or "GDI accelerator cards") this applies only to GDI (and DirectDraw but that's another topic altogether). GDI+, which is what System.Drawing uses, is completely done in software.

    So while 2D operations in GDI can be accelerated, the same is not true for GDI+.

    Of course drawing with GDI+ will at some point end up drawing to a GDI device context, and it may be accelerated at that point. But the difference is clear: if you scale a bitmap with GDI, this can be done with a scaled bitblt which is often hardware accelerated. If you scale the same bitmap with GDI+, the scaling is done in software (and is typically of a much higher quality as a result).

  • To SpongeJim's question, this is done by the MIL (media integration layer), which is the underlying core of WPF that handles composition. On a Vista/Vista remote desktop connection, the MIL primitives are remoted and then reconstituted. On other combinations (e.g. 2003/XP), what gets remoted is bitmaps, which is obviously far more bandwidth-intensive. More depth on this topic can be found on Greg Schechter's blog, and in this entry in particular: http://blogs.msdn.com/greg_schechter/archive/2006/06/09/623566.aspx

  • Thanks for the clarification, Sven - that's helpful.

  • Изначально, WPF разрабатывался для работы только под Windows Vista, а на XP SP2 был сделан так называемый

  • I'm disappointed to hear that WPF is accelerated in XP just like in Vista.  I haven't yet found a WPF sample application that runs on my XP box without pegging the processor.  I have a GeForce 6600 which should be DX9 compliant.  Maybe I need to double check to make sure it fully supports DX9 and PS2.0.  I was hoping that an upgrade to Vista would solve the performance problems.  That healthcare sample app MS released runs dog slow in XP on every system I own.

Page 1 of 2 (21 items) 12