TurboVNC is a high-speed version of VNC derived from TightVNC. It contains a variant of Tight encoding that is tuned to maximize performance for image- intensive applications (such as VirtualGL, video applications, and image editors) while still providing excellent performance for other types of applications.

TurboVNC, in combination with VirtualGL, provides a complete solution for remotely displaying 3D applications with interactive performance.

TurboVNC is the product of extensive research, in which many different permutations of the TightVNC encoder were benchmarked at the low level against a variety of captured RFB sessions that simulate real-world application workloads, both 2D and 3D. TurboVNC's encoding methods have been adopted by TigerVNC, libvncserver, and others.


  • Fine-grained control over the JPEG image quality and the level of chrominance subsampling
  • Double buffering on the client side to reduce tearing artifacts in 3D and video applications
  • Flexible and configurable full-screen/multi-screen support
  • Full support for IPv6
  • Advanced flow control and continuous updates. This allows clients to receive framebuffer updates without specifically requesting them, which can improve performance dramatically on high-latency connections.
  • Authentication with one-time passwords or Unix login credentials. Access control lists can be used to share VNC sessions with only certain users.
  • TurboVNC allows security/authentication policies to be set globally for a particular server machine.
  • Multithreaded Tight encoding
  • "Lossless refresh" allows a viewer to request a lossless copy of the current screen image. This is useful in situations in which image quality is critical but the network is too slow to support sending a high-quality image for every frame. Lossless refreshes can be performed manually when a certain hotkey is pressed, or the TurboVNC Server can be configured to send a lossless refresh automatically if the user stops interacting with the application for a certain period of time.
  • A high-performance Java viewer, deployable using Java Web Start. This viewer is based on the TigerVNC Java viewer but has numerous additional features, the most notable of which is the ability to accelerate JPEG decompression by calling libjpeg-turbo through JNI. This gives the Java TurboVNC Viewer similar levels of performance to the native TurboVNC Viewer.

On "modern" hardware, TurboVNC is capable of streaming 50+ Megapixels/second over a 100 Megabit/second local area network with perceptually lossless image quality. TurboVNC can stream between 10 and 12 Megapixels/second over a 5 Megabit/second broadband connection at reduced (but usable) image quality.

TurboVNC is compatible with other VNC distributions, particularly with those that also support Tight encoding (such as TigerVNC, TightVNC, and UltraVNC.)

What's New

Significant changes relative to 3.0.2:

  • Fixed an issue in the Windows TurboVNC Viewer whereby a left Alt key press, followed by a left Alt key release, caused the keyboard focus to be redirected to the system menu, and subsequent keystrokes were consumed by the system menu until left Alt or Esc was pressed to dismiss the menu.
  • Fixed an issue whereby Rosetta was required in order to install the TurboVNC package for Macs with Apple silicon CPUs.
  • Fixed a regression introduced by 2.2 beta1[7] that prevented the idle timeout feature in the TurboVNC Server from working properly.
  • The Mac TurboVNC Viewer app now informs macOS that it supports HiDPI monitors. This improves the sharpness of the remote desktop and TurboVNC Viewer GUI when using a Retina display.
  • Fixed a regression introduced by 3.0 beta1[24] that caused the TurboVNC Server to become unresponsive if the network connection dropped and a VNC viewer disconnected before the network connection was restored.
  • The vncserver script no longer passes -rfbwait 120000 to Xvnc. Effectively, that hard-coded the TurboVNC Server's send/receive timeout to 120 seconds, which doesn't make sense for most modern systems and networks. (The default value if -rfbwait is not passed to Xvnc is 20 seconds, which makes more sense.) The previous behavior can be restored by adding -rfbwait 120000 to the $serverArgs variable in turbovncserver.conf.
  • Fixed an issue in the TurboVNC Viewer that sometimes caused the Java process to crash when closing the viewer window, particularly if multiple connections were open.
  • Fixed a regression introduced by 3.0.1[3] whereby the TurboVNC Viewer's built-in SSH client tried the ssh-rsa, rsa-sha2-256, and rsa-sha2-512 signature schemes in sequence for every RSA private key stored in the SSH agent, even if the SSH server did not support one or more of those signature schemes. This caused the SSH client to prematurely exceed the SSH server's maximum number of authentication attempts.
  • Fixed an issue in the TurboVNC Viewer's built-in SSH client whereby SSH private keys specified using the SSHKey and SSHKeyFile parameters or the IdentityFile OpenSSH config file keyword were added to the SSH agent's persistent keychain. The SSH client now maintains its own temporary keychain rather than modifying the agent's keychain.
  • To better emulate the behavior of OpenSSH, the TurboVNC Viewer's built-in SSH client has been improved in the following ways:
  • If the SSH agent already has a copy of an SSH private key that was specified using the SSHKey or SSHKeyFile parameter or the IdentityFile OpenSSH config file keyword, then the SSH client now promotes the agent's copy of the key to the head of the SSH client's keychain rather than adding a duplicate key to the end of the keychain. If the SSH agent does not have a copy of the specified SSH private key, then the SSH client now adds the new key to the head of its keychain if a valid passphrase for the key was specified or to the end of its keychain if a valid passphrase for the key was not specified.
  • The TurboVNC Viewer now treats ~/.ssh/id_ecdsa as a default private key. Each of the default private keys ~/.ssh/id_rsa, ~/.ssh/id_dsa, and ~/.ssh/id_ecdsa, in that order, will be added to the SSH client's keychain using the rules described above if the file exists and the SSHKey and SSHKeyFile parameters are not specified.
  • +, ^, and - can now be used at the beginning of the PubkeyAcceptedAlgorithms OpenSSH config file keyword to specify a set of algorithms that should be appended to, prepended to, or removed from the default list.
  • Fixed a regression introduced by 2.2.1[5] that caused the PreferredAuthentications OpenSSH config file keyword to be ignored.