我在15Mbit / s网络上使用x11vnc,延迟为20ms.当屏幕变化很多时,x11vnc很慢 – 例如当我在浏览器中切换选项卡时,几乎需要两秒钟才能完全重绘视图.
奇怪的是,x11vnc的最大连接速度在缓慢重绘时仅为可用带宽的10％左右.为什么x11vnc没有使用可用带宽来加速重绘？例如,scp正在使用100％的可用带宽而没有问题.
如何确定系统中x11vnc的瓶颈是什么？到目前为止,我认为：
> 10％的网络使用率=>网络不是瓶颈
> fb读取速率：601 MB /秒=>读fb不是瓶颈
任何想法如何进一步分析x11vnc并找出导致减速的原因？
解决方法
回答我自己的问题：
从紧密编码切换到六边形编码解决了完全缓慢重绘的问题.
添加一些细节：我注意到在缓慢重绘屏幕期间,客户端上的cpu达到了100％的使用率.我使用的是紧密编码,从页面VNC Tight Encoder – Comparison Results可以看出,与hextile编码相比,紧密编码非常密集.切换到hextile max cpu后,使用率绝不是100％,几乎可以利用整个可用带宽,重绘总是不到一秒钟.所以客户端的cpu是瓶颈.
或者甚至更好的替代方案(更少的带宽,更低的cpu使用率,似乎甚至比六角形更快)到compile x11vnc with TurboVNC support然后使用TurboVNC client.
