There have been some recent changes for the RTM versions of Windows 7 and Windows Server 2008 R2 related to where content is rendered (client or host) when remoted over RDP 7. Read on to learn more about what has changed, and how various types of content are remoted in the final version of RDP7.
In pre-release Windows 7 and Windows Server 2008 R2 we provided the ability to remote GDI, DirectX 10.1/DXGI 1.1, Direct2D, Aero Glass experience, and media with Windows Media Player using a client-based rendering technique. This has the advantage of utilizing available client side CPU/GPU resources to do all the rendering and rasterization of the graphical data.
Other content types, such as WPF, Silverlight, Flash, and DirectX 9 applications, were remoted using our enhanced bitmap acceleration feature in R2, where host-side CPU/GPU resources are utilized to perform the rendering and rasterization on the host before sending these bitmaps efficiently over the network.
In the RTM version of Windows 7 and Windows Server 2008 R2, GDI applications, media with Windows Media Player, and Aero Glass will continue using the client-side rendering for remote scenarios as demonstrated in the pre-release version. For the RTM release, client-based rendering will no longer be available for DirectX 10.1 / DXGI 1.1 and Direct 2D applications, instead this type of content will be remoted using host-side resources leveraging the enhanced bitmap acceleration capabilities in R2. This decision was made based on the feedback we received during the engineering and validation process, where the number one requirement was quality and robustness. While this design change may impact the utilization of CPU and GPU resources on the host side for certain use cases, it provides a consistent approach to remoting multiple types of rich (2D and 3D) content across a broad range of rich and thin client devices.
Holy Wild Frozen Cow !!
This is terribly stupid.
I fully support the view that the option should be given to the admin to decide whether to user the local resource to render or the server host to render it.
terrible idea... Guess we have to wait for win8 to include that feature... Hate 7 being stripped down to less features more and more...
Client-side DirectX/OpenGL rendering has been the dream RDP feature as long as there have been GPUs. Why put a $$$ GPU in a business box if it isn't used to its full potential.
Will G ChromeOS server-side rendering be slower and more expensive than a MS Hyper-V 2008 R2 server I will have to maintain and patch forever?
Like said before, this is terribly STUPID.
We built a whole business case on this single feature alone because we control the software and we're able to build against DirectX 10.1 with remoting.
We're heading to the cloud, we need to run those app instances in the cloud but we definitely need to lower power consumption on the server side by avoiding to put 3D cards in every server chassis.
Your host-side enhanced bitmap acceleration capabilities can't even support 10 simultaneous clients.
you really didn't realize the consequence of this choice, we would have deployed R2 on thousands of nodes, now we're going to cancel the project.
"This decision was made based on the feedback" ?
Which feedback ? 'cause the only feedback i can see here is : DO IT !
Even if it's a dirty reg switch, give us the choice !
15 years in the field advocating your products, Microsoft, i'm really disappointed.
Thanks for all the feedback. Appreciate if you can use the E-mail feature on the blog and describe in greater detail your use case for building a new DirectX 10.1 / DXGI 1.1 application and deploying it for remote access from Win 7 clients to WS08 R2 RDSH servers.
Gaurav, in the scenario of high resolution and high fps data, the preferred solution would come down to bandwidth comsumption to minimize a lag in video output to the client.
Im assuming bandwidth that by streaming the rendering to the client is less bandwidth intensive than sending 1920x1080 bitmap data compressed (lossless compression?) at 30-60fps to the client.
An an outsider, I can see some really cool idea's come from this, just as VM's have taken off. Game companies offering Games on demand (ie. no download), that are always updated because their on the cloud and protection against piracy. Of course, latency and bandwidth are the two key problems in this scenario, but Im assuming your dismissing an opportunity to reduce bandwidth consumption and offload cpu/gpu cycles to the client by your decision.
A better design is to provide options that can be changed or customized by users or admin.
For example DirectX 10.1->client-rendering, GDI-> host rendering, Direct2D->client rendering, etc. And the option can be changed from Advanced RDP7 options(Warning: Ignored if you connect to non Windows Server 2008 R2 )
By changing the options users or admin can scale the application or server resources itself.
Also users can use either thin or thick client.
So this proposed design will satisfies all type of users, no more complaints from anybody. To implement this design is not very painful for you MS. Since you already do some part of it.
This is a request from a larger pool of customers.
Absolutely Ridiculous MICROSOFT... why tease it in RC and Yank it out in RTM..make no sense at all... Very Disappointed!!
Pulling this feature all-together is absolutely ridiculous, you have no idea how many people saw this one feature(which you presented), and had their jaw's drop to the ground, effortless client-side rendering has been a dream for a long time, I don't understand why you wouldn't deploy it, especially since everything is already done on your end.
This lost Microsoft a complete conversion for us. 250 Windows 7 clients and 30 servers.
Thanks to the constant feature pull, the decision has been made to stay with 2K3 and XP, all now served entirely as VDI, and considered "legacy applications."
$250,000 that would have gone to getting our suppliers to port their apps properly to Win 7 has now been reinvested to porting those same apps (supported) to RHEL 5. All desktops are undergoing conversion to RHEL as we speak, and we estimate that within 3 years we will have been able to abandon MS all together.
This is entirely due to the decision to pull client-side rendering of DirectX 10.1, a feature we had been counting on to support several future projects in-house. Instead, it will all be recoded for X11. (Go go X11 forwarding.)
So thank you. Thank you a great deal. After 10 long years of lobbying, your decisions to pull this feature, (oh, and the Ribbon Bar, that also won no friends,) enabled me to finally convince my workplace to abandon Microsoft. Microsoft's project managers truely must be the strongest supporters of open source alive.
We were about to go a full terminal services model for most of our clients based upon the performance of the RC. This represents over 1000 clients.
The cloud had finally become a reality.
Now every client asks "What about flash?" (youtube etc)
So we're going with Citrix HDX instead based upon this stupid decision. A real shame indeed.
How is the decision to remove client-side DX remoting related to Flash, as these are different technologies?
Yes, if you need additional graphics or management features, Microsoft has partners like Citrix (XenDesktop and XenApp) and Quest (vWorkspace) that offer such capabilities. Citrix HDX uses their ICA (Independent Computing Architecture) protocol and Quest (the company I work for) extends RDP with support for things like Flash Multimedia (Youtube). The companies also come into play if you want such features from non-Windows clients like Mac or Linux (for example).
vWorkspace 7 has Flash and Windows Multimedia redirection for XP, Vista, Win7, 2003, 2008 and R2, 32 Bit and X64, VDI and RDS, as well as Windows And non-Windows clients.
How would the performance be if the server was gpu based. CUDA?
A previous poster (L) asked: "What about switching from one remoting model to the other according to the capabilities or the device, and/or providing control over the remoting model as configuration options on the client?"
I like this suggestion, but unlike L , I would like to have the option of using the host side device. My remote machine has a high end NVIDIA CUDA device that is not recognised remotely. I suspect that this is because the application is being redirected to use locally available devices.