Windows Presentation Foundation (WPF) has an interesting feature called Remoting where it is able to render primitives over Remote Desktop by sending primitives over the network instead of raw bits. While I believe this already happened in XP for some GDI primitives, as far as I know this is the only way to send hardware accelerated 3D across the wire, since regular Direct3D rendering gets remoted at the bitmap level instead of the primitive level. Well, according to a blog post from a WPF member (http://blogs.msdn.com/jgoldb/archive/2008/05/15/what-s-new-for-performance-in-wpf-in-net-3-5-sp1.aspx), this got neutered not too long ago:
Although we have not improved this scenario, it is important to highlight some differences related to Remoting
On .Net Framework 3.0 and .Net Framework 3.5:
- Vista to Vista with DWM on, we Remoted content as Primitives (e.g. the channel protocol went over the network) (This is for the Remote Desktop case only, not Terminal Server)
- In other cases: we Remoted content as Bitmaps
On .Net Framework 3.5 SP1
- 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.
- Although this could be seen a regression at first, depending on the complexity of the application scene (e.g. very rich scenes) this can actually improve performance in certain scenarios . Also, connections with reasonably high bandwidth and scenarios that donít involve a lot of animation or 3D, for instance, tend to remote just fine via bitmaps.
Ouch. I haven't looked into this deeply, but if I interpret this correctly, this means that the remoting advantage of WPF is effectively gone with .NET 3.5 SP1, because WPF apps are now going to be remoted just like any other app that's using a rendering method other than GDI, i.e. as an image. The comment about wpfgfx.dll vs. milcore.dll also implies that there isn't much, if any, advantage that WPF gives you over Direct3D API-wise. For a while I was wondering if it would be worth trying hacks to get WPF or at least MILCORE usable from native code without having to spin up the CLR, but this is looking increasingly less useful since I already have a reasonably powerful Direct3D9 layer and an image resampler that is probably faster than WPF's new shader JIT. Not to mention that, unless it's been added since the original API, WPF's support for offscreen rendering is a bit lacking.
I do wonder about the pixel shader JIT, though... as usual I take any claims about speed from Microsoft with skepticism, but on the other hand, it can't possibly be any slower than refrast. Anyone played around with the new JITter? Show me the assembly. :)