我在15Mbit / s的网络上使用x11vnc，延迟为20ms。当屏幕变化很大时，x11vnc速度很慢-例如，当我在浏览器中切换选项卡时，将视图完全重新绘制大约需要两秒钟。
奇怪的是，即使在缓慢重绘时，x11vnc的最大连接速度也仅约为可用带宽的10％。为什么x11vnc不使用可用带宽来加快重绘速度？例如，scp正在毫无问题地使用100％的可用带宽。
如何确定系统上x11vnc的瓶颈？到目前为止，我认为：
有什么想法可以进一步分析x11vnc并找出导致速度下降的原因吗？
例如，x11vnc是否有任何开关可以显示正在处理的数据量以及抓取屏幕，处理和压缩并通过网络发送它需要多长时间？
Answers:
要回答我自己的问题：
从严格编码转换为六角编码解决了重新绘制缓慢的问题。
要添加一些细节：我注意到，在缓慢重绘屏幕时，客户端上的cpu达到了100％的使用率。我使用的是紧密编码，从“ VNC紧密编码器-比较结果 ”页面中可以看出，与六角编码相比，紧密编码的CPU占用率很高。切换到最高的最大cpu使用率永远不会达到100％之后，几乎会使用整个可用带宽，并且重绘总是花费不到一秒钟的时间。因此，客户端的CPU是瓶颈。
甚至更好的选择（更少的带宽，较低的cpu使用率，甚至看起来似乎比hextile更快）是使用TurboVNC支持编译x11vnc，然后使用TurboVNC客户端。
原因是屏幕捕获/渲染器效率低下。许多不同的VNC实施都与此相关，以实现更好的性能。
如果您不需要完全反映本地控制台上的内容，则更好的解决方案是将NoMachine的NX或FreeNX作为远程桌面环境。与VNC相比，即使在WAN链路上，性能也是白天和黑夜。
我希望这应该起作用。http://www.karlrunge.com/x11vnc/faq.html#faq ...搜索VNC查看器参数和x11vnc参数：
它为我工作。