Freigeben über


Comparing WPF on Windows Vista v. Windows XP

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!

Comments

  • Anonymous
    January 06, 2007
    Thanks, that was useful.   Does the same hold true for Windows 2003?

  • Anonymous
    January 06, 2007
    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

  • Anonymous
    January 07, 2007
    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
  • Anonymous
    January 07, 2007
    The comment has been removed

  • Anonymous
    January 07, 2007
    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

  • Anonymous
    January 07, 2007
    Thanks!

  • Anonymous
    January 07, 2007
    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

  • Anonymous
    January 08, 2007
    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

  • Anonymous
    January 08, 2007
    Hi Tim, How exactly is Vista (DX?) serializing/deserializing 3D information for remoting purposes?

  • Anonymous
    January 08, 2007
    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).

  • Anonymous
    January 08, 2007
    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

  • Anonymous
    January 08, 2007
    Thanks for the clarification, Sven - that's helpful.

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

  • Anonymous
    January 09, 2007
    The comment has been removed

  • Anonymous
    February 04, 2007
    Hi Steve Hiner, do you have the most current nvidia drivers installed? I've seen similar problems on other machines with a out-of-date forceware driver.

  • Anonymous
    February 23, 2007
    Which version of GDI+ is 'supported' in Vista? gdiplus.dll version 6.x (as included in office 2003) or only the 'old' WinXP version?

  • Anonymous
    March 01, 2007
    Does have GDI+ hardware acceleration on Vista for native code app?

  • Anonymous
    March 26, 2007
    why is windows vista greater than windows xp?

  • Anonymous
    July 13, 2007
    I was involved in a conversation this week where someone mentioned "it's just 2 lines of code", So I

  • Anonymous
    July 13, 2007
    I was involved in a conversation this week where someone mentioned "it's just 2 lines of code"