x11vnc 很慢，但只使用了 10% 的可用带宽

Question

我在 15Mbit/s 网络上使用 x11vnc，延迟为 20 毫秒。当屏幕变化很大时 x11vnc 很慢 - 例如，当我在浏览器中切换选项卡时，视图完全重绘需要将近两秒钟的时间。

奇怪的是，x11vnc 的最大连接速度即使在慢速重绘期间也只有可用带宽的 10% 左右。为什么 x11vnc 不使用可用带宽来加速重绘？例如 scp 使用 100% 的可用带宽没有问题。

如何确定系统上 x11vnc 的瓶颈是什么？到目前为止我认为：

1. 10% 网络使用率 => 网络不是瓶颈
2. fb 读取率：601 MB/秒 => 读取 fb 不是瓶颈

任何想法如何进一步分析 x11vnc 并找出导致速度放缓的原因？

例如，x11vnc 是否有任何开关来显示它正在处理多少数据以及抓取屏幕、处理和压缩它并通过网络发送它需要多长时间？

Answer 1

回答我自己的问题：

从紧编码切换到十六进制编码完全解决了重绘缓慢的问题。

添加一些细节：我注意到在缓慢重绘屏幕期间，客户端上的 CPU 使用率飙升至 100%。我使用的是紧编码，从页面VNC 紧编码器 - 比较结果可以看出，与十六进制编码相比，紧编码是相当消耗 CPU 的。切换到十六进制最大 cpu 使用率永远不会是 100%，几乎整个可用带宽都被利用了，重绘总是不到一秒钟。所以客户端的CPU是瓶颈。

或者甚至更好的替代方案（更少的带宽，低 CPU 使用率并且似乎比 hextile 更快）是使用 TurboVNC 支持编译 x11vnc，然后使用TurboVNC 客户端。