Recent Changes - Search:

TurboVNC Home

About TurboVNC




Developer Info


Related Projects

What About TigerVNC?

The TigerVNC Project was founded by some of the former TightVNC developers, Red Hat, and The VirtualGL Project in early 2009, with the goal of providing a high-performance VNC solution based on the RealVNC 4 and code bases. Throughout 2010 and 2011, The VirtualGL Project contributed many hours of labor (probably half of them pro bono) to the development of TigerVNC, in hopes of turning TigerVNC into "TurboVNC 2.0." Ultimately, however, it became apparent that, both from a technological and a political point of view, making TigerVNC into a TurboVNC work-alike was going to be like fitting a square peg into a round hole. Unlike TurboVNC, TigerVNC is not focused on 3D and video applications, so its developers were not generally very concerned with making such applications performant by default. Further, there was resistance to including some of TurboVNC's 3D-specific features, such as automatic lossless refresh, in TigerVNC. In general, there was also just an irreconcilable clash of project management styles. Thus, with the release of TigerVNC 1.2.0, The VirtualGL Project stepped down as a contributor and supporter of TigerVNC in order to focus on moving TurboVNC forward.

The following summarizes the strengths of TigerVNC and TurboVNC, from an end user's point of view.


  • Very stable -- over a decade of enterprise testing and productization, and thousands of seats in large corporations and academia (read more about our success stories here.)
  • The ability to set global security/authentication policies for a particular server machine (including disabling clipboard transfer and reverse connections, limiting the remote desktop size, requiring SSH tunneling, and disabling particular authentication methods)
  • One-time password support (useful when building web portals around TurboVNC)
  • User access control lists (for sharing sessions with specific users)
  • Lossless refresh and automatic lossless refresh features
  • More attractive and feature-rich VNC viewer GUI
    • Uses the system's look & feel rather than FLTK.
    • Provides a toolbar for easy access to common features
    • Provides an application menu on OS X
  • Support for the full-screen application feature in OS X 10.7 "Lion" and later
  • More configurable and flexible full-screen and multi-screen support
    • Supports offset screens or screens with differing resolutions
    • Allows the user to specify whether a non-full-screen window should maximize across one or multiple screens
    • Automatic selection of single-screen or multi-screen spanning based on the remote desktop resolution
  • Full documentation and complete man pages
  • Multi-threaded Tight encoding
  • Lossless Tight encoding method for high-speed networks (approximates the bandwidth usage of Hextile and uses very little CPU time)
  • More configurable and flexible keyboard grabbing feature (TigerVNC can only grab the keyboard in full-screen mode.)
  • Default settings are designed to provide peak LAN performance for 3D and video apps.
  • Self-contained X server code base that is fully integrated into the TurboVNC build system
  • Better support for IPv6
  • Java viewer can achieve native levels of performance by calling libjpeg-turbo through JNI.
  • Built-in web server serves up the Java TurboVNC Viewer via Java Web Start, along with the libjpeg-turbo JNI libraries for popular platforms (for a complete zero-install high-performance VNC viewer solution)
  • Fully integrated SSH support
    • -via and -tunnel options on all platforms
    • Built-in SSH key management in the Java viewer
    • GUI support for SSH tunneling in the Java viewer
  • As much as 8-10x better viewer performance on OS X than TigerVNC
  • TLS encryption using either OpenSSL or GnuTLS (TigerVNC uses only GnuTLS. OpenSSL has better performance.)
  • Remote X Input and Wacom tablet support
  • NV-CONTROL extension support


  • module for providing VNC access to the "root" X display (requires building TigerVNC against the same version of that your system uses.) Our alternative to this is to use x11vnc in libvncserver 0.9.9, which uses the TurboVNC encoder.
  • Native language support
  • Xinerama support

Differing Approaches

TigerVNC, owing to its RealVNC heritage, is really designed to be built against a distribution-supplied X server code base and SDK. There are advantages to that approach. For starters, it offloads the burden of fixing X server issues to the O/S distributor, and there is less chance of incompatibilities between Xvnc and the window managers that are bundled with the distribution (since Xvnc is essentially running the same X server code as the "root" X server.) However, there are drawbacks to TigerVNC's approach as well. The biggest is that building TigerVNC from source requires a distribution-specific procedure, which is typically undocumented and difficult for many developers to figure out. We attempted to work around this by providing a "cross-compatible build" of TigerVNC, but that has a whole different set of issues. It requires building all of the infrastructure from source, which is very slow and cumbersome, and if any issues are discovered in that specific code base, they are difficult to address without upgrading one or more of the components (which creates all new issues.) Additionally, the cross-compatible build required a separate static build of GnuTLS and, on some platforms, gettext, which required the maintainer to keep abreast of security changes in those packages. In short, TigerVNC is really meant to be supplied by an O/S distributor.

TurboVNC's approach is instead to integrate a well-known X server code base into its source tree, so any issues that are discovered with it can be fixed within our project. This means that interaction issues between new window managers and our version of Xvnc have to be addressed by us, not by the distribution vendor. However, it also means that once an issue is fixed, it is fixed on all platforms. Using an in-tree X server code base makes our server much easier and quicker to build, and it puts us in complete control over the quality of the solution.


TigerVNC 1.2.x, 1.3.x, and 1.4.3 and later can be configured to provide similar performance to the most common modes of operation in TurboVNC (assuming that multithreading is not being used in the latter, and assuming a Windows or Linux client. The TigerVNC Viewer currently suffers from a severe performance loss on OS X, due to unknown reasons.) The following table lists equivalent settings between the two solutions:

TurboVNC SettingsTigerVNC 1.2.x/1.3.x/1.4.3+ Settings
JPEG Image Quality = 92
JPEG Chrominance Subsampling = 1X
Compression Level = 1
Interframe Comparison = off
(Rough equivalent to "Tight + Perceptually Lossless JPEG", but with slightly lower image quality)

Compression Level = 1
JPEG Quality Level = 8
JPEG Image Quality = 77
JPEG Chrominance Subsampling = 2X
Compression Level = 7
Interframe Comparison = on
(Rough equivalent to "Tight + Medium-Quality JPEG", but with slightly lower image quality and more Zlib compression)

Compression Level = 2
JPEG Quality Level = 5
JPEG Image Quality = 29
JPEG Chrominance Subsampling = 4X
Compression Level = 7
Interframe Comparison = on
(Rough equivalent to "Tight + Low-Quality JPEG", but with slightly lower image quality)

Compression Level = 2
JPEG Quality Level = 1

However, it should be noted that, due to a performance regression, TigerVNC 1.4.0 - 1.4.2 cannot be configured to perform as well as TurboVNC under any circumstances. More information can be found here.

Creative Commons LicenseAll content on this web site is licensed under the Creative Commons Attribution 2.5 License. Any works containing material derived from this web site must cite The VirtualGL Project as the source of the material and list the current URL for the TurboVNC web site.

Edit - History - Print - Recent Changes - Search
Page last modified on December 04, 2016, at 05:15 PM