Why is VNC on Windows so slow?

Solution 1:

VNC is just plain inefficient. VNC works pretty much by taking a series of screenshots, compressing them, and slinging them across the network

On Windows, RDP will give you better performance, but you need professional or better on the server/source end for proper RDP I believe.

wierdly remote assistance may work better for your needs -its RDP with both the user at the terminal, and the user at the remote system seeing the same screen

EDIT: 4 years on, I'm using nomachine for similar tasks - would work across OSes, and does a few other useful things.

Solution 2:

VNC is not comparable to video streaming. In video streaming you typically transfer a pre-compressed video stream via the network. For HD streams it's often H.264 encoded. If you use VNC then your host computer has to take screen snapshots and compress them before sending them on to the network. There are several constraints here:

• Strong compression needs a lot of CPU power. For example encoding a 90 minutes movie in H.264 in high quality often takes more than 4 hours compression time on my Athlon X2 4450e server. Usually such strong compression is unsuitable for real-time applications like remote control.
• Less strong compression in turn will require more network bandwidth which might become an issue on low-bandwidth connections like the internet.

Well, there are a couple of "tricks" which are applied by video codecs and remote control and screen-sharing utilities. First of all they try to detect the screen changes and transfer the (compressed) image of the changes only. This usually saves A LOT of bandwith and processing power. However for full-screen video transfer it does not help a lot since the whole screen has to be re-transferred too often. As written above current machines will probably be unable to rel-time encode your screen content in Full-HD and stream it to a remote-control application since your host will have to decode the video content and then re-encode the raw images before sending them to the network. Some older Dual-Core machines are even at the limit when decoding Full-HD video content. Not even speaking about having to re-encode the Full-HD images on screen again before sending them to the VNC client.

To improve your VNC remote-control speed you can do the following:

• Most VNC servers/clients support multiple compression algorithms. Some of them are optimized for small bandwidth, some for good image quality and some for low latency. This touches another aspect of remote control. Since the service is interactive latency matters (you don't want to see the reaction to a mouse click just after 5 minutes of encoding).
• Try to reduce the amount of screen changes on your host machine. For example try disabling Windows desktop effects, animations etc. This saves bandwitdth as only changed parts of the screen are transferred over network.
• Try disabling further visual effects on the host like transparency. Transparent Windows as used by Vista/Win7 reduce the "compressability" of images. Uni-colored/"flat" areas are much more efficient to compress than vibrant colors and fancy details. So disabling Aero transparency and desktop effects really speed up remote control experience. Most remote control tools even allow to disable such effects automatically on connect (e.g. Microsoft RDP and some VNC implementations).
• Same applies to background pictures. Try using uni-colored background setting instead of HD pictures.

Another issue for VNC is that it has to detect the changes on your screen. Some VNC implementations do "dumb" screenshots and compare them to the previous screenshot to detect changes. This is taking a lot of power already. Some more advanced implementations work with special display drivers (check UltraVNC) which are more efficient here but require special drivers to be installed.

Of course all this does not help if you're playing a video on your host machine. In this case VNC will have to re-encode ~30 full-screen images per second and send it via network. On most compressions which can be performed in real-time by todays CPUs such a stream would take > 8Mbps of bandwidth. So it's unsuitable for most internet connections (especially think about asymmetric DSL connections with typically less than 1Mbps upload speed, and yes, it's upload speed which matters on host side).

It might be suitable for LAN use, but here you should probably more think about setting up a media server or share your media using DLNA/UPnP media server (even Win7 media player can do this). Then use a DLNA client to play the shared media.

Solution 3:

The absolute fastest VNC variant I've ever used is UltraVNC with the Video Mirror Driver installed. RDP is still noticeably faster, but it's not nearly as bad.

I've also heard really good things about ZeroRemote, but never tested it. It appears that TrueRemote is its successor.

Solution 4:

If you're trying to watch video across a LAN, the fastest solution in terms of sheer screen-drawing speed is probably Radmin.