我正在使用超过15Mbit / snetworking的x11vnc，时延为20ms。 当屏幕变化很多时，x11vnc很慢 – 例如当我在浏览器中切换标签时，需要将近两秒钟才能完全重绘视图。
奇怪的是x11vnc的最大连接速度在慢速重绘时只有10％的可用带宽。 为什么x11vnc不使用可用带宽来加速重新绘制？ 例如scp使用100％的可用带宽没有问题。
我怎样才能确定我的系统上x11vnc的瓶颈？ 到目前为止我认为：
任何想法我怎么能进一步剖析x11vnc并找出是什么导致放缓？
例如，是否有任何交换机x11vnc显示它处理了多less数据，以及抓取一个屏幕需要多长时间，处理和压缩它并通过networking发送？
回答我自己的问题：
从紧密编码切换到六重编码解决了整个缓慢重绘的问题。
添加一些细节：我已经注意到，在缓慢重画屏幕的过程中，客户端上的cpu达到了100％的使用率。 我正在使用严格的编码，从页面VNC紧密编码器 – 比较结果可以看出，紧密编码相当于cpu密集型相比，六重编码。 切换到hextile以后，cpu的使用率绝不是100％，几乎可以利用整个可用带宽，重绘总是不到一秒钟。 所以客户的CPU是瓶颈。
或者更好的select（带宽更less，CPU使用率低，似乎甚至比hextile更快）是编译x11vnc支持TurboVNC ，然后使用TurboVNC客户端 。
原因是屏幕捕获/渲染器效率低下。 许多不同的VNC实现与此有关，以实现更好的性能。
如果您不需要准确反映本地控制台上的内容，更好的解决scheme是将NoMachine的NX或FreeNX作为远程桌面环境。 与VNC相比，即使在WAN链路上，性能也是白天和黑夜。
我希望这应该工作。 http://www.karlrunge.com/x11vnc/faq.html#faq …searchVNC查看器参数和x11vnc参数：
它为我工作。