Changes to Remoting Model in RDP 7

re: Changes to Remoting Model in RDP 7

L. — Sun, 21 Jun 2009 13:21:10 GMT

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).

re: Changes to Remoting Model in RDP 7

hannespreishuber — Sun, 21 Jun 2009 15:25:56 GMT

so this means, WPF is still rendered on server?

re: Changes to Remoting Model in RDP 7

David Rottenberg — Mon, 22 Jun 2009 00:44:59 GMT

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?

re: Changes to Remoting Model in RDP 7

Gaurav Daga [MSFT] — Mon, 22 Jun 2009 04:04:42 GMT

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.

@hannespreishuber

WPF - yes, rendered on the server.

@David Rottenberg

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.

re: Changes to Remoting Model in RDP 7

David Rottenberg — Mon, 22 Jun 2009 06:41:19 GMT

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.

Thank you,

David.

re: Changes to Remoting Model in RDP 7

Gaurav Daga [MSFT] — Mon, 22 Jun 2009 07:12:22 GMT

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

re: Changes to Remoting Model in RDP 7

Rei — Mon, 22 Jun 2009 09:27:14 GMT

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.

re: Changes to Remoting Model in RDP 7

Daniel — Mon, 22 Jun 2009 11:41:33 GMT

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..

re: Changes to Remoting Model in RDP 7

Nik — Mon, 22 Jun 2009 15:08:24 GMT

@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.

Nik.

re: Changes to Remoting Model in RDP 7

KnightHawk — Tue, 23 Jun 2009 02:48:20 GMT

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.

re: Changes to Remoting Model in RDP 7

Gaurav Daga [MSFT] — Tue, 23 Jun 2009 05:23:01 GMT

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.

re: Changes to Remoting Model in RDP 7

Rakesh — Tue, 23 Jun 2009 15:46:39 GMT

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

re: Changes to Remoting Model in RDP 7

DirectXGod — Tue, 23 Jun 2009 17:44:25 GMT

http://www.brianmadden.com/blogs/brianmadden/archive/2009/06/22/Microsoft-makes-a-post_2D00_RC-change-for-RDP7_3A00_-no-more-client_2D00_rendered-DirectX.aspx

re: Changes to Remoting Model in RDP 7

Fri, 26 Jun 2009 00:37:31 GMT

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)

re: Changes to Remoting Model in RDP 7

dierk — Sun, 28 Jun 2009 12:02:27 GMT

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

regards,

dierk

re: Changes to Remoting Model in RDP 7

CK — Sun, 28 Jun 2009 13:58:21 GMT

Holy Wild Frozen Cow !!

This is terribly stupid.

re: Changes to Remoting Model in RDP 7

Baradharajan — Mon, 29 Jun 2009 15:17:42 GMT

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.

re: Changes to Remoting Model in RDP 7

Sebastian Foss — Sun, 05 Jul 2009 09:18:22 GMT

terrible idea... Guess we have to wait for win8 to include that feature... Hate 7 being stripped down to less features more and more...

re: Changes to Remoting Model in RDP 7

G ChromeOS — Thu, 09 Jul 2009 00:17:37 GMT

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?

re: Changes to Remoting Model in RDP 7

pierre — Fri, 24 Jul 2009 19:11:18 GMT

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.

re: Changes to Remoting Model in RDP 7

Gaurav Daga [MSFT] — Fri, 24 Jul 2009 19:30:26 GMT

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.

re: Changes to Remoting Model in RDP 7

Tim — Mon, 27 Jul 2009 15:47:54 GMT

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.

Provide choice to admins and/or end users

youknow — Sun, 23 Aug 2009 22:00:59 GMT

A better design is to provide options that can be changed or customized by users or admin.

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.

re: Changes to Remoting Model in RDP 7

Clifton — Mon, 24 Aug 2009 18:27:46 GMT

Absolutely Ridiculous MICROSOFT... why tease it in RC and Yank it out in RTM..make no sense at all... Very Disappointed!!

re: Changes to Remoting Model in RDP 7

Adam — Fri, 28 Aug 2009 03:03:04 GMT

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.

re: Changes to Remoting Model in RDP 7

Will Alden — Tue, 03 Nov 2009 06:40:25 GMT

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.