Are there problems with rendering WPF over Remote Desktop under Windows XP?

Scott James picture Scott James · Oct 13, 2008 · Viewed 8k times · Source

I have heard that WPF primitives will not be supported by remote desktop on windows XP. The implication of this is that if you run a WPF application on a vista machine and display it on an XP machine (via remote desktop) the display will be sent as a compressed bitmap.

This issue is resolved in Vista-Vista comunication via DirectX 11 (?) but this will not be made available on XP. There is obviously a performance hit here, I would like to understand it before making any inroads into developing applications to WPF.

Some information on this topic can be found here:

http://blogs.msdn.com/tims/archive/2007/01/05/comparing-wpf-on-windows-vista-v-windows-xp.aspx

See comment from the above link (quote):


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


Does anyone have any experience or more up to date information on this issue?

Answer

Bradley Grainger picture Bradley Grainger · Oct 13, 2008

As of .NET 3.5 SP1, all WPF graphics are remoted as bitmaps, even on Vista-to-Vista communication. From http://blogs.msdn.com/jgoldb/archive/2008/05/15/what-s-new-for-performance-in-wpf-in-net-3-5-sp1.aspx:

We now remote as bitmaps in ALL cases.

The reason is that WPF 3.5 SP1 now uses a new graphics DLL (wpfgfx.dll) and certain changes could not be made to Vista’s existing graphics DLL (milcore.dll) that is also used by DWM.

As other commenters have noted, the performance will greatly depend on the design of your application’s UI. The potential upshot is that you only have to test in one scenario; remoting performance should now be the same regardless of the client or server.