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

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.

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.

Dig Deeper on Desktop Virtualization Networking

5 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close