Microsoft makes a post-RC change for RDP7: no more client-rendered DirectX - Brian Madden -
Brian Madden Logo
Your independent source for desktop virtualization, consumerization, and enterprise mobility management.
Brian Madden's Blog

Past Articles

Microsoft makes a post-RC change for RDP7: no more client-rendered DirectX

Written on Jun 22 2009 13,678 views, 5 comments

by Brian Madden

On Friday Microsoft announced (via an MSDN blog post) some major changes to the way RDP will work in Windows 7 and Windows Server 2008 R2. This is interesting because both of those products are currently available as release candidates now. These changes are NOT in the current release candidates, but will be made before RTM.

So what's changed? First of all, everything we're talking about here has to do with the location of where different types of content are rendered (client-side or server-side). Friday's blog post announced some changes about what's rendered where.

How we thought RDP 7 would work (up until last week)

Before we get into the specifics of the changes that were announced, we should look at what we thought we knew about how RDP 7 was going to split up the rendering tasks. In any server-based computing environment, your remote display protocol can work two ways:

  • For "server-side" (or "host-side") rendering, all of the graphics processing happens on the server side, and then then rasterized images (or subsets of those images) are sent down to the client. The advantage of this is that the client can be extra dumb, because it doesn't need to know how to do anything apart from putting together the image elements it receives.
  • For "client-side" rendering, the remote host sends the raw instructions down to the client so that the client actually constructs the screen elements. The advantage of this is that it typically requires less bandwidth and definitely requires less processing on the server-side, although it also requires a higher-capability on the client as the client has to be able to understand the specific instructions and have enough hardware to build the screen elements.

So for example, imagine you're using an OpenGL application via a remote display protocol. If a "server-side rendering" model was used, the server hardware would process the OpenGL commands and turn them into the nice images that appear on the screen. Then the remote display driver would "scrape" that image and send it to the client. On the other hand, a "client-side rendering" model would mean that the remote server would simply send the OpenGL commands to the client, where the client would process them and draw the nice image itself. As we touched on briefly, each has its advantages and disadvantages.

Microsoft's RDP protocol has been a combination of server-side and client-side rendering, depending on the specific type of screen element in question. Up until last week, here's how we thought RDP 7 would handle the various rendering:

Server-side / host-side rendered:

  • WPF
  • Silverlight
  • Flash
  • DirectX content prior to 10.1

Client-side rendered:

  • Remote GDI
  • DirectX 10.1/DXGI 1.1
  • Direct2D
  • Aero Glass experience
  • Windows Media Player content

Changes to RTM version

Based on Friday's blog post, the new RDP7 rendering location list looks like this:

Server-side / host-side rendered:

  • WPF
  • Silverlight
  • Flash
  • DirectX (all versions)
  • Direct2D

Client-side rendered:

  • Remote GDI
  • Aero Glass experience
  • Windows Media Player content

In other words, Microsoft has decided that the DirectX-based functions will ALL be host-rendered (via technology they got when they bought Calista), and that client rendering will not be an option. A few people are freaking out in the comments section of the MSDN blog post, but I don't think this is a big deal. What's important to note is that the DirectX functionality was only for DirectX 10.1 apps (i.e. only for apps written for a version of DirectX that's not even out yet), and even then, the apps have to be written using specific remoting-capable options.

To me it's most interesting that the change occurred post-release candidate, and is being made "based on the feedback we received during the engineering and validation process, where the number one requirement was quality and robustness." So it's cool to know that Microosft is willing to step up and pull this feature if it's not ready.

The bottom line is that this isn't too big of a deal. I'm mostly writing this post because I love RDP 7 and I'm really excited about it. I'm worried that this might get blown out of proportion, so I'm stepping in to point out that this change is actually quite small and will probably not affect anyone.


Our Books


Rene Vester wrote re: Microsoft makes a post-RC change for RDP7: no more client-rendered DirectX
on Mon, Jun 22 2009 6:19 AM Link To This Comment

Especially the remoting-specific development was the challenge i saw. Would be huge expectations from the customers and in most cases it would end in disappointment as developers are not following the remoting guidelines, so i think you are right, better out.. than half in..

/Rene Vester

Tim Mangan wrote re: Microsoft makes a post-RC change for RDP7: no more client-rendered DirectX
on Mon, Jun 22 2009 8:37 AM Link To This Comment

This is dissapointing, but hopefully it is a glitch

and they will eventually overcome it.

Brian - in the OpenGl example I think you intended to say the server side software (not hardware) renders the graphics primitive into bitmaps.

appdetective wrote re: Microsoft makes a post-RC change for RDP7: no more client-rendered DirectX
on Mon, Jun 22 2009 4:04 PM Link To This Comment

It wil be interesting to see how well Callista performs over a network and how bandwidth hungry it is or isn't. The fact that MS is removing choice just presents opportunties for real world protocols not half assed attempts from Microsoft which are not meant to address complex use cases. Microsoft is only interested in addressing mass use cases for the average guy, never anything complex, they leave that to partners. The fact that they paid 125M for Callista have done next to nothing with it, 240M, super slow softgrid development, 110M Kidaro pick up to introduce a joke feature for Win 7, just shows how much they don't care about this space to address complex organizations. Joe average is their market the rest will always be frustrated.

Shawn Bass wrote re: Microsoft makes a post-RC change for RDP7: no more client-rendered DirectX
on Tue, Jun 23 2009 2:43 PM Link To This Comment

Clarification:  Not all DX 10.1 applications were rendered client side with Win7 RC1.  Only DX 10.1 apps that were coded to use the DX10.1 Remoting APIs would in fact be client side rendered.  While there are lots of DX 10.x apps out there, very little of them are using the DX10.1 remoting APIs.  However, this is still an unfortunate move for those ISVs that might want to take advantage of this technology for their apps.  I assume that this also means that D2D is not being remoted as well.  This is also unfortunate, but in the grand scheme of things there's little applications out there written to use 10.1 Remoting or D2D, so there's little right to existing applications.  However, it doesn't paint a good picture for the future apps.


Neil Spellings wrote re: Microsoft makes a post-RC change for RDP7: no more client-rendered DirectX
on Wed, Jun 24 2009 3:49 AM Link To This Comment

I think this change gives Citrix a good opportunity to retain their lead over RDP when they release their HDX technologies for ICA.

As it stood with the 2008 R2 RC, RDP would gain features not present in ICA. Now, the gap will be much reduced, allowing Citrix to get their HDX DirectX remoting into the marketplace first and retain ICA as the "premier" remoting protocol.

All those developers bitching about not being able to run their DirectX 10.1 apps with client-side rendering will then have an (expensive, admittedly) solution via XenApp or XenDesktop that will allow them to work.

(Note: You must be logged in to post a comment.)

If you log in and nothing happens, delete your cookies from and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.