我在 15Mbit/s 网络上使用 x11vnc，延迟为 20ms。当屏幕变化很大时，x11vnc 很慢 - 例如，当我在浏览器中切换选项卡时，需要将近两秒钟才能完全重新绘制视图。
奇怪的是，即使在缓慢重绘期间，x11vnc 的最大连接速度也只有可用带宽的 10% 左右。为什么 x11vnc 不使用可用带宽来加快重绘速度？例如，scp 使用 100% 的可用带宽却没有问题。
如何确定我的系统上 x11vnc 的瓶颈是什么？到目前为止，我认为：
- 10% 网络使用率 => 网络不是瓶颈
- fb 读取速率：601 MB/秒 => 读取 fb 不是瓶颈
有什么想法可以让我进一步分析 x11vnc 并找出导致速度变慢的原因？
例如，x11vnc 是否有任何开关可以显示它正在处理多少数据以及抓取屏幕、处理和压缩并通过网络发送需要多长时间？
答案1
回答我自己的问题：
从紧密编码切换到十六进制编码彻底解决了重绘缓慢的问题。
补充一些细节：我注意到在屏幕缓慢重绘期间，客户端的 CPU 使用率飙升至 100%。我使用的是紧密编码，从页面VNC Tight Encoder - 比较结果可以看出，与六边形编码相比，紧密编码对 CPU 的占用相当大。切换到六边形后，最大 CPU 使用率永远不会达到 100%，几乎整个可用带宽都被利用，并且重新绘制总是需要不到一秒的时间。因此，客户端的 CPU 是瓶颈。
或者甚至更好的替代方案（更少的带宽，更低的 CPU 使用率，甚至比 hextile 更快）是使用 TurboVNC 支持编译 x11vnc然后使用TurboVNC 客户端。
答案2
原因是屏幕捕获/渲染器效率低下。许多不同的 VNC 实现尝试一下这种方法，以获得更好的性能。
如果你不需要准确反映本地控制台上的内容，更好的解决方案是NoMachine 的 NX或者自由NX作为远程桌面环境。即使通过 WAN 链接，其性能也与 VNC 相差无几。