Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects


Blog Archive

Avalon remoting is now a whole lot less attractive

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 (, 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. :)


This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.