开发预计通过 RDP 运行的应用程序； 有小费吗？
假设我正在开发一个图形密集型应用程序（C++ 或 C#，图形 API 未确定），其大部分使用将由远程用户通过 RDP（终端服务器会话或对单用户计算机的远程访问）进行。 显然，应该避免非必要的“养眼”效果和动画。 我的问题是：
为了最有效地利用 RDP 协议，我应该注意做什么/避免做什么？ （例如，我有一个想法 RDP 可以将一些图形绘制基元直接远程到客户端...但这仅适用于 GDI 吗？使用双缓冲是否会破坏这种远程处理并强制使用位图模式？客户端位图缓存是否“只是工作”还是只缓存某些内容（例如字体和图标）？）
是否有任何类型的 RDP 协议分析器可用，可以深入了解 RDP 流实际传输的内容（特别是位图与绘图基元）？ （我可以想象向 rdesktop 源添加一些工具来执行此操作，但也许已经存在一些东西）。
Supposing I was developing a fairly graphically intensive application (C++ or C#, graphics API undecided) for which most of the usage will be by remote users over RDP (either terminal server sessions or remote access to a single-user machine). It's obvious that non-essential "eye-candy" effects and animations should be avoided. My questions are:
What should I be careful to do/avoid doing to make most efficient use of the RDP protocol ? (e.g I have an idea RDP can remote some graphics drawing primitives straight to the client... but is that only for GDI ? Does using double-buffering break such remoting and force a bitmap mode ? Does the client-side bitmap cache "just work" or does it only cache certain things like fonts and icons ?)
Is there any sort of RDP protocol analyser available which will give some insight into what an RDP stream is actually transporting (in particular, bitmaps vs drawing primitives) ? (I can imagine adding some instrumentation to the rdesktop source to do this, but maybe something exists already).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据我的经验，在动画方面我会小心 - 特别是淡入/淡出控件，它会严重影响 RDP 的性能。
双缓冲也可能会导致一些问题，但是我个人并没有为此做太多的解决方法 - Raymond Chen 的文章很好地解释了可能存在的陷阱。
从本质上讲，检查代码是否在远程会话（RDP、Citrix 等）中运行是一个好主意。 看一下：
GetSystemMetrics( SM_REMOTESESSION )- 然后您可以在运行时决定是否启用或禁用某些功能。In my experience I'd be careful when it comes to animations - especially fade up/down controls that can seriously kill performance over RDP.
Double-buffering might also cause some problems, however I personally haven't had to do too much in the way of workarounds for this - the article by Raymond Chen explains the possible pitfalls quite well.
Essentially, it's a good idea to check in code whether it's running in a remote sessions (RDP, Citrix, etc). Take a look at:
GetSystemMetrics( SM_REMOTESESSION )- you can then decide at runtime whether to enable or disable certain features.我的想法是，在 RDP 上进行的优化工作已经涵盖了您所描述的 90% 的问题，所以我不会担心 RDP 的优化，您已经删除了养眼的东西，您知道该应用程序将通过 RDP 使用，所以我想您将避免涉及连续重绘表单的操作，我相信这就足够了。
我们的应用程序在设计时从未考虑到 RDP，当客户告诉我们其所有客户端都将通过 RDP（在特定情况下是 Citrix）从远程位置使用时，我们也有同样的担忧，但如果我们不进行更改由于 RDP，客户从未因缓慢问题而调用过一行代码。
请记住...过早的优化是邪恶的。
My idea is that the optimization work made on RDP already cover 90% of the problem you're describing, so I would not worry about optimizing for RDP, you're already removed the eye-candy stuff, you know that the application will be used via RDP so I suppose you'll avoid operations that involves continuous redrawing of form, I believe that sould be enough.
Our application was never designed with RDP in mind, we had the same worries you have when a customer told us that all its client will be used via RDP (Citrix, in that specific case) from remote locations but also if we didn't change a single line of code the customer never called with slowlyness problems due to RDP.
Remember... Premature optimization is evil.