• View
• Edit
• History
• Print

TurboVNC or TigerVNC?

The TigerVNC Project was founded by some of the former TightVNC developers, Red Hat, and The VirtualGL Project in early 2009, and it aims to provide a high-performance VNC solution based on the RealVNC 4 and X.org code bases. Unlike TurboVNC, TigerVNC is not specifically focused on 3D and video applications, and thus TurboVNC remains the X proxy of choice for VirtualGL. However, although The VirtualGL Project no longer actively participates in the development of TigerVNC, VirtualGL works well with it. The following summarizes the strengths of TigerVNC and TurboVNC, from an end user's point of view.

TurboVNC

• Very stable -- 8+ years 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, 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
• Pseudo-double buffering to prevent tearing artifacts with 3D and video applications (TigerVNC partially supports this, but their viewer implementation sometimes draws the screen in the middle of a frame, particularly on slower connections.)
• Rich Windows VNC viewer GUI
• Full documentation and complete man pages
• Multi-threaded encoding (multi-threaded decoding slated for next major release)
• Lossless Tight encoding method for high-speed networks (approximates the bandwidth usage of Hextile and uses very little CPU time)
• Fully configurable and flexible full-screen and multi-screen support on Linux and Windows clients (for instance, the ability to use vncviewer with offset screens or screens with differing resolutions, to specify whether a window should maximize across one or multiple screens, etc.)
• Keyboard grabbing feature that allows special window manager keystrokes, such as Alt-Tab, to be sent to the server
• Default settings are designed to provide peak LAN performance for 3D and video apps
• Fully self-contained X server code base
• Full support for IPv6
• Java viewer can achieve "near-native" levels of performance by calling libjpeg-turbo through JNI
• Fully-integrated SSH support (including -via and -tunnel options on all platforms and built-in SSH key management in the Java viewer)
• Much better performance on OS X

TigerVNC

• Better VNC viewer GUI on Linux
• Built-in encryption and advanced authentication via VeNCrypt (the Java TurboVNC Viewer supports this, but not the native viewers or the server.)
• X.org module for providing VNC access to the "root" X display (requires building TigerVNC against the same version of X.org that your system uses.) Our alternative to this is to use x11vnc in libvncserver 0.9.9, which uses the TurboVNC encoder.
• The remote desktop can be dynamically resized (slated for the next major release of TurboVNC)
• Native language 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 the code requires a distribution-specific procedure, which is typically undocumented and difficult for many developers to figure out. We attempted to work around that by providing a "cross-compatible build" of TigerVNC, but that has a whole different set of issues. It requires building the complete X.org infrastructure, which is very slow and cumbersome, and if any issues are discovered in that specific X.org 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.

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 makes our server much easier and quicker to build, and it puts us in complete control over the quality of the solution.

Performance

The latest version of TigerVNC as of this writing (1.2) can be configured to provide similar performance to the most common modes of operation in TurboVNC (assuming that multi-threading 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: