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.
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? Client side rendering is much better in low bandwidth scenarios (e.g. remote access through the uplink of an ADSL line).
so this means, WPF is still rendered on server?
I just saw this yesterday, a post where you decided to disable DirectX client side rendering. This is a terrible idea. It takes something that was massively scalable, where a server could serve lots of 3d stream to clients and clients would do the rendering. To something that doesn't scale now. You guys just lost tons of sales for Windows7. We were relying on this feature for our customer and were going to move them to Win7. There is no reason now. They can stay with XP and we'll use Citrix Apollo project. Really to do bad on your part. Who makes these decisions at Microsoft? Sounds like someone decided that this was too hard to QA, so let's disable it or is there a more sinister reason?
RDP 7 does make certain decisions on optimizing the protocol traffic based on the administrator / user choice specified in the Remote Desktop Connection -> Options -> Experience tab connection speed setting - this is to optimize performance for best user experience. However this does not include deciding whether to do client-side or host-side rendering, this decision is based on content type as described in this article.
WPF - yes, rendered on the server.
Thanks for the feedback David. What applications are being used by your customer? The client-based rendering was provided in pre-release versions of Windows 7 and Windows Server 2008 R2 only for brand new written applications that use the new DirectX 10.1 / DXGI 1.1 API introduced in Windows 7. All existing DirectX applications would anyway go through host-based rendering. Please test the latest available versions of Windows 7 or Windows Server 2008 R2 for your customer's DirectX applications - there are many enhancements in RDP 7 for performance, scale, and user experience that are applicable to even host-rendered applications.
It is a classified application that I can't say much about. It was being written in DirectX10 (well, more like ported from DirectX9). We relied on the fact that the app can run in virtual machines on the server Win2008 R2 and then get rendered on the client and not the server. Now it will get rendered with a software renderer on the server - slow - then will get compressed and send to the client. So, instead of us scaling to 1000 app instances, this now may scale to 10 maybe 20 instances. This is all I can tell you about the app.
This is a really bad decision. Is there anyway you can reconsider or add an option where one can direct where the rendering should be done: client or host.
Thanks for the information on the application. The only way to measure the scale of a deployment is to actually test it with the latest available version of Windows Server 2008 R2 - I will encourage you to try the application on a Remote Desktop Session Host.
As for running DirectX applications on Windows Server 2008 R2 Hyper-V virtual machines, there will be the GPU offload hardware assist Calista technologies at some point in the future: http://blogs.msdn.com/rds/archive/tags/Calista/default.aspx
I already start development of new server-client graphic application depends on new RDP7 model. Because the most (rack of blade) server GPU is very poor but desktop client GPU is rich.
This change is very terrible. Can you add the option or manifest to use client-side GPU? Robustness is not matter when the application source is owned.
Would it be possible to make this an advanced option for those who would like to opt in (at the expense of robustness, which could be tested in their particular case)? I think this would be the best decision..
@Gaurav Daga [MSFT]
I think, the best idea in this situation will be some kind of experimental (and officialy unsupported) registry key (or policy setting) to enable DirectX client-side rendering. Disabled by default, of course. This days it's normal practice to add experimental features in RTM, because users will be able to evaluate them in real life and send feedback. Refer to Hyper-V beta in Win2K8 RTM.
I have to agree with some others yanking this at the last minute is not cool and not going to win you any fans, many were looking forward to this.
while I understand the majority can get by without it use cases remain where this is preferred or needed, or already started to be counted on. As Nik mentioned keeping it in there as an experimental technically unsupported option enabled by a regkey would seem to me like the better option if technically possible.
Thanks for all the feedback.
It required a rewritten/ported or brand new DirectX 10.1 application application using the new DirectX 10.1 / DXGI 1.1 API and the remoting specific guidelines introduced in Windows 7 to get client-based rendering over RDP in the Windows Server 2008 R2 pre-release version - and client-based rendering would have been available when connecting from pre-release Windows 7 rich client devices only. It will be very interesting to see test (performance / scale) results for any such newly written real life application over this configuration.
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 < 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. To implement this design is not very painful for you MS. Since you already do some part of it.
Please do it at least in next service pack of Windows Server 2008/ Windows 7.
A well wisher
I'm completely with the rest of the comments. this is a terrible idea not to just make it an option and decrease the investment in client rendering features (regardless of the callista acquisition). distributed computing (including graphics) are only going to become more powerful over time, not less and the move to a centralized model is just backwards.
why would microsoft want to spark a relegious debate here? just do both. $61B in sales should buy the ability to develop more than one feature and i agree with the comment that this will provide yet another feature to push people off of XP and onto Windows 7 (presumably the most important thing Microft could be thinking about right now for increased share-holder value)
To extend server side hw acceleration support for more DirectX versions is a first step in the right way BUT support for OpenGL - which is the std. for professional applications - is a still missing feature
would Microsoft support OpenGL hw acceleration in the future