Tim Mangan on How Microsoft will Enhance RDP and why this is Important

In the "Chat with Microsoft Execs," Bob Muglio answered a question about Avalon extending to RDP clients that have WinFX (maybe an RDP6?). I have been working my way through the blizzard of Microsoft information and found an interesting gem that could be what he is talking about, and it would affect the future of the terminal server market.

In the "Chat with Microsoft Execs," Bob Muglio answered a question about Avalon extending to RDP clients that have WinFX (maybe an RDP6?). I have been working my way through the blizzard of Microsoft information and found an interesting gem that could be what he is talking about, and it would affect the future of the terminal server market.

Both RDP and ICA work by taking graphics primitives in the kernel, down near the video driver (termdd). When they can, they try to use GDI objects instead of bitmaps, but bitmaps end up being the “lowest common denominator” when pictures and shading (pixilation) are use. In any case, these are graphical objects rendered on the server to a resolution for a 2D display “virtual screen”. These protocols do a pretty good job to figure out what has changed and, compressing to reduce bandwidth, shipping them over the wire. 

One of the ideas that have been out there for years to enhance terminal server has been to grab the graphics at an earlier point closer to the application and send that over the wire for local rendering instead. But it has only been an idea (I am aware of one implementation, but it was not commercially available. Brian may remember a conversation he and I had about it the first time we met!)

Up on Channel 9 there is a video (link below, this is not the same video as the Channel 9 Terminal Server video that Brian linked to several months ago) of Chris Anderson, who is the architect at Microsoft for Avalon (now called Windows Presentation Foundation), the graphics end of the new Vista/Longhorn platforms. In this video he describes how terminal services could hook into the new graphics primitives. Chris does not talk time-frames or releases, but his talk does offer the possibility of doing all the graphics rendering on the client device instead of on the terminal server. Bob and others seemed to imply a Longhorn timeframe for this functionality in the chat and only if the Client has WinFx.

This would be a significant development for terminal server. It would open up the deployment of graphic rich applications on terminal servers. Things like AutoCad, or MSC, or even video games! These are significant applications that should be centralized on a hunkin’ piece of iron that is near large storage capacity. By offloading the graphics rendering to a more capable device we can have the best of both worlds. Certainly 2D zoom and rotate could be done at the client. If the graphic objects could be 3D objects, then 3D rotation would also be local. Now this only works with a thin-device with a good graphics card--but it beats buying a $10k workstation since CPU and storage are not important--and has to have WinFx capability.

You can see the Video here:  http://channel9.msdn.com/Showpost.aspc?postid=67522

The video is a technical white board talk covering the internal architecture of the new graphics system, and it helps a whole lot if you already understand how the current graphics system, including User32, termdd and the like work. He gets into that about half way through--roughly the 6 minute mark. Also in the chat area of that web page is a pretty good diagram in a post by Tom Servo that I think is helpful--although an educated “guess” at how this stuff lays out.

PS: I am pretty sure that this does not spell trouble for Citrix. They likely will be able to hook in the same way. In fact, having two implementations of this level of remoting UI will probably produce a better result for all of us.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

https://www.brianmadden.com/forum/micons/m4.gifIt seems that if you are not currently in channel9, the posted link to the video does not work.  So here is how to find the video:
Go http://channel9.msdn.com
On the left side select Avalon.
Click on the Video tab
Look for “Chris Anderson – Talking shop about Avalon”.  It is about the 9th video.
https://www.brianmadden.com/forum/micons/m6.gifThanks to Tore Solberg for noticing!
I ran across this while googling a while back and played with the demo, but I don't know what kind of bandwidth it used or what the client requirements are:
We did have discussions about WinFx & Avalon graphics via RDP but it sounded like what you're reporting, that this would only work on a Vista Client. 
The idea of sending the graphics calls over the wire might sound good but the bandwidth required would be huge for 3D scenes of any size.  In effect,  the wire would have to handle the amount of data that is now sent between a CPU and a Graphics card (e.g. PCI Express or AGP speed).  On very small 3D scenes this might work okay but so would the current RDP which uses software to render the 3D scenes.  CAD,  Engineering and other 3D apps would not perform well at all.  On bitmaps the current RDP will max out at about 10 frames per second and will use about 40mb/sec of bandwidth.
A direct example is found in the Unix world.  Hummingbird makes a product that sends the 3D primatives from a Unix machine to a Windows client.  The calls are then rendered in the video card of the client.  This works well on a LAN (except on large data sets that can kill even a gigabit network) but it has no chance to work well over the Internet,  hence Hummingbird never made an Exceed 3D on demand product but did make an Exceed on demand product for 2D apps.
As Patrick mentions,  ThinAnywhere is the only option. It uses a very low end client that doesn't even need a 3D graphics card.  It will work great on a LAN or WAN and utilizes the graphics card in the server (with multiple users per card and multiple cards).  Depending on the application and Window size ThinAnywhere will deliver at least 10 frames per second at T1 speed and upwards of 50 frames per second with modest bandwidth.
RE: Vista.  The server would have to be Longhorn (or whatever they name it).  The client need not be Vista.  Microsoft covers Avalon based apps on XP and above via .net2.0
RE: Bandwidth.  You wouldn't be sending over the whole model.  Since I originally wrote this (it got lost for a while) Citrix showed some amaizing 3d rendering at iForum as part of "constelation" (this was part of the Boeing demo) that I suspect would have been using this technique.
Not that OpenGL is a bad thing either. 
This is a very interesting case of coming "Full Circle". In essence we are reinventing X Windows here. That is, the client device actually is the graphics server (renderer), this has clearly proven itself to be a better approach for graphics intensive applications. The downside has always been the required bandwidth, which is generally greater in this scenario. However, broadband has become very common and in many cases this may not prove to be an issue.
Now that we have reinvented X Windows we should expect to see a very large Citrix mainframe on the market soon :)
I, personally, am not convinced this is a good direction.  the key to TS has always been because it's server side like the mainframe.  by the way, winframe/terminal services is = mainframe.  X windows <> mainframe.  x windows and mainframe tech are two different things.
I'm not sure if that'll make ppl using terminals happy.
Dumb terminals would be useless right?
So you'd still need fat(ter) clients to do the rendering.