TurboVNC was originally a fork of TightVNC 1.3.x, and on the surface, the X server and Windows viewer still behave similarly to their parents. However, the current version of TurboVNC contains a much more modern X server code base (based on X.org 7.7) and a variety of other features and fixes not present in TightVNC, including a high-performance Java viewer. In addition, TurboVNC compresses 3D and video workloads significantly better than the “tightest” compression mode in TightVNC 1.3.x while using only typically 15-20% of the CPU time of the latter. Using non-default settings, TurboVNC can also match the best compression ratios produced by TightVNC 1.3.x for 2D workloads. Furthermore, TurboVNC contains some unique features that are designed specifically for visualization applications.

All VNC implementations, including TurboVNC, use the RFB (remote framebuffer) protocol to send “framebuffer updates” from the VNC server to any connected "viewers." Each framebuffer update can contain multiple "rectangles" (regions that have changed since the last update.) As with TightVNC, TurboVNC analyzes each rectangle, splits it into multiple "subrectangles", and attempts to encode each subrectangle using the "subencoding type" that will provide the most efficient compression, given the number of unique colors in the subrectangle. The process by which TurboVNC does this is referred to as an "encoding method." A rectangle is first analyzed to determine if any significant portion of it is solid, and if so, that portion is encoded as a bounding box and a fill color ("Solid subencoding.") Of the remaining subrectangles, those with only two colors are encoded as a 1-bit-per-pixel bitmap with a 2-color palette ("Mono subencoding"), those with low numbers of unique colors are encoded as a color palette and an 8-bit-per-pixel bitmap ("Indexed color subencoding"), and subrectangles with high numbers of unique colors are encoded using either JPEG or arrays of RGB pixels ("Raw subencoding"), depending on the encoding method. zlib can optionally be used to compress the indexed color, mono and raw subrectangles.

Part of TurboVNC's speedup comes from the use of libjpeg-turbo. However, TurboVNC also eliminates the CPU-hungry smoothness detection routines that TightVNC 1.3.x used to determine whether a subrectangle is a good candidate for JPEG compression, and TurboVNC's encoding methods tend to favor the use of JPEG more, since it is now generally the fastest subencoding type. Furthermore, TurboVNC eliminates buffer copies, it maximizes network efficiency by splitting framebuffer updates into relatively large subrectangles, and it uses only the zlib compression levels that can be shown to have a measurable performance benefit.

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 and libvncserver.

In addition to high performance, other notable features of TurboVNC include:

  • 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.

TurboVNC, when used with VirtualGL, provides a highly performant and robust solution for remotely displaying 3D applications over all types of networks.

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.)