I am using x11vnc over 15Mbit/s network with 20ms latency. When the screen is changing a lot x11vnc is slow – for example when I switch a tab in a browser, it takes almost two seconds until the view is fully redrawn.
The strange thing is that max connection speed of x11vnc is even during slow redrawing only about 10% of the available bandwidth. Why is x11vnc not using available bandwidth to speed the redrawing up? For example scp is using 100% of available bandwidth without problems.
How can I identify what is the bottleneck for x11vnc on my system? So far I think:
- 10% network usage => network is not a bottleneck
- fb read rate: 601 MB/sec => reading fb is not a bottleneck
Any ideas how can I further profile x11vnc and find out what is causing a slowdown?
For example is there any switch for x11vnc to show how much data it is handling and how long it takes to grab a screen, process and compress it and send it over the network?
Best Answer
To answer my own question:
Switching from tight encoding to hextile encoding resolved the problem with slow redrawing completely.
To add some detail: I have noticed that during slow redrawing of the screen the cpu on the client was spiking to the 100% usage. I was using tight encoding and from the page VNC Tight Encoder - Comparison Results it can be seen that tight encoding is quite cpu intensive when compared to hextile encoding. After switching to hextile max cpu usage is never 100%, almost the whole available bandwidth is utilized and redrawing always takes less than a second. So the client's CPU was the bottleneck.
Or even better alternative (less bandwidth, low cpu usage and seems even faster than hextile) is to compile x11vnc with TurboVNC support and then use TurboVNC client.