X11-转发和效率

我有一个图形密集型应用程序，需要通过X11转发。我花了一些时间研究X11及其效率（包括效率），包括这篇出色的文章：为什么X11转发如此低效？。

对于我来说，还不清楚的一件事是X11转发的性能是否取决于应用程序。我觉得无论发生什么情况，整个屏幕都可以转发。然后，X11转发应该与应用程序无关。

那么，关于实际转发的内容以及ssh -X的性能是否取决于应用程序，是否有任何具体信息？

我觉得无论发生什么情况，整个屏幕都可以转发。然后，X11转发应该与应用程序无关。

不，实际上是相反的。X11转发之所以称为“ X11转发”，是因为它传输应用程序用来在“ X服务器”（通常是Xorg）上呈现其窗口的实际X协议消息。这些消息是用于创建/移动窗口，绘制文本和图形图元（直线/矩形），绘制位图等的命令。

您可以说这在概念上与 “全屏图像”协议（例如VNC / RFB）相反。我认为它可以与Windows的RDP媲美，后者也是用于传输GDI绘图命令的。

因此，您看到程序之间差异的原因是：

1. 为了引用您所引用的文章，最初大多数基于X的程序都是这样工作的：

   基本上，X11不会将屏幕发送到您的计算机，但会发送显示指令，以便本地计算机上的X服务器可以在本地系统上重新创建屏幕。

   因此，当一个程序想要显示一个按钮时，它只发送了一些简短的命令-“绘制矩形”，“绘制文本”，也许还有一些使其看起来像3D的线。

2. 随着时间的变化，程序开始自行进行渲染，其中许多指令变成“这是我已经渲染的位图，将其显示在屏幕上” –在本地非常快，但是由于X11缺少任何内容，因此在网络上非常慢图像压缩。

   这意味着使用现代工具包构建的程序在联网的X11上要慢得多，即使它与抗锯齿字体一样基本。

   （相比之下，RDP已随着时间的推移进行了调整，并包括各种形式的图像压缩，例如JPEG甚至是H.264；在加载完整图像时，您通常会注意到压缩伪像。）

3. 幸运的是，大多数UI工具包（例如GTK）都实现了损坏跟踪，因此仅重新发送更新的区域。但是，某些程序（例如Firefox / Thunderbird的多个版本）不支持此功能，并且要求完全重新渲染整个窗口，即使尚未真正更新也是如此。

   这是程序之间的另一个区别–行为良好的程序仍然可以在网络上使用，但是有错误的程序可以使100 Mbps的链路饱和，而实际上没有任何用处。