X11 - 转发和效率

Question

X11 - 转发和效率

12

我有一个图形密集型的应用程序需要通过X11转发。我花了一些时间研究X11及其（不）高效性，包括这篇很棒的文章：为什么X11转发如此低效？。有一件事对我来说仍然不太清楚，那就是X11转发的性能是否取决于应用程序。我之前的理解是整个屏幕都会被转发，无论发生什么情况。那么X11转发应该是与应用程序无关的。所以，是否有关于实际被转发的具体信息，以及ssh -X的性能是否取决于应用程序的确切信息呢？

- Fang

2是的。首先，可以参考 Daniel Stone 在 2013 年的 LinuxConf.au 上的演讲《背后的真实故事：Wayland 和 X》（视频链接）。 - user11574

1我之前的理解是整个屏幕都被转发了。很难理解你是如何得出这样的印象的，因为人们通常在SSH X转发中手动在远程shell上运行单独的应用程序；你能否详细说明一下你是如何启动这些应用程序的？ - rakslice

1如果您通过SSH隧道传输X会话，有一个需要注意的因素：ssh可以进行压缩。这是命令行上的-C选项或者.ssh/config文件中的Compression: yes选项。如果您在拥挤的T1链路上从达拉斯传输到澳大利亚的传统X转发，这可能是在界面中打开一个五层深度对话框并从一个不切实际的任务选择复选框，与仅仅令人非常沮丧的两个小时之间的区别。幸运的是，我还没有尝试过在Wayland上进行此操作，但我认为它已经得到了极大的改进。 - Ed Grimm

我不想在评论区展开一场广泛的讨论，尤其是因为我的问题已经得到了@grawity的很好回答。当我说“整个屏幕”时，我指的是通过ssh隧道转发的数据将始终是屏幕上像素的简单描述。@EdGrimm：谢谢你对压缩的评论。我意识到这一点。在我们特定的情况下，X11通过10Gbit LAN链路转发，压缩与否似乎完全没有任何区别。 - Fang

1个回答

相关问题

- user1686 · Accepted Answer

我原本以为整个屏幕都会被转发，不管发生什么情况。然后X11转发应该是与应用程序无关的。不，事实上恰恰相反。之所以称为“X11转发”，是因为它传输应用程序用于在“X服务器”（通常是Xorg）上渲染窗口的实际X协议消息。这些消息是用于创建/移动窗口、绘制文本和图形基元（线条/矩形）、绘制位图等的命令。你可以说它在概念上与VNC/RFB等“全屏图像”协议相反。我认为它在某种程度上类似于Windows的RDP，也是用于传输GDI绘图命令的。所以你看到程序之间差异的原因是：引用您所提到的帖子，最初大多数基于X的程序是这样工作的：基本上，X11不会将屏幕发送到您的计算机，而是发送显示指令，以便本地计算机上的X服务器可以在本地系统上重新创建屏幕。因此，当程序想要显示一个按钮时，它只需发送几个简短的命令 - "绘制一个矩形"，"绘制文本"，也许还有一些线条使其看起来像3D。随着时间的推移，情况发生了变化，程序开始自己进行渲染，其中许多指令变成了"这是我已经渲染好的位图，请将其放在屏幕上" - 在本地非常快速，但由于X11缺乏任何图像压缩，通过网络传输非常慢。这意味着使用现代工具包构建的程序在网络化的X11上要慢得多，即使只是基本的抗锯齿字体。（相比之下，RDP随着时间的推移进行了适应，并包括各种形式的图像压缩，如JPEG甚至H.264；在完整图像加载时，您经常会注意到压缩伪影。）幸运的是，大多数UI工具包（如GTK）实现了损坏跟踪，因此只重新发送更新的区域。然而，一些程序（如几个Firefox/Thunderbird版本）不支持此功能，并请求完全重新渲染整个窗口，即使它实际上没有更新。这是程序之间的另一个区别 - 表现良好的程序在网络上仍然非常可用，但有缺陷的程序可能会在完全没有做任何有用工作的情况下占用100 Mbps的链路。