• View
• Edit
• History
• Print

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 X.org 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. Furthermore, 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.

TurboVNC

• Very stable -- has been enterprise-tested and productized since 2004 and has thousands of seats in large corporations and academia
• Multiple simultaneous VNC sessions under the same user account
• Dynamic VNC display number assignment (TigerVNC requires VNC display numbers to be statically assigned to user accounts by the system administrator)
• Users can start/stop VNC sessions (TigerVNC sessions must be started/stopped by the system administrator.)
• 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)
• 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 macOS
• Support for the full-screen application feature in OS X/macOS 10.7 "Lion" and later
• Client-side remote desktop scaling
• More configurable and flexible full-screen and multi-screen support
  • Supports offset monitors and monitors with differing resolutions
  • Allows the user to specify whether a non-full-screen viewer window should span one or multiple monitors
  • Automatic selection of single-monitor or multi-monitor spanning based on the remote desktop resolution
  • Allows the user to remotely configure any multi-screen Xinerama layout on the server, or to specify a multi-screen layout using the server's -geometry argument
  • In both windowed and full-screen modes, automatic desktop resizing chooses a server-side screen layout that honors the client's screen boundaries and taskbar/menu bar location.
• Full documentation and complete man pages
• Lossless Tight encoding method for high-speed networks (has approximately the same network footprint as Hextile while using about half the 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 applications.
• 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.
• 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
• Approx. 8-10x better aggregate viewer performance on macOS than TigerVNC
• TLS encryption using OpenSSL, which has better performance than GnuTLS
• Remote X Input and Wacom tablet support
• NV-CONTROL extension support
• Built-in UltraVNC Repeater support
• Can connect to encrypted Vino sessions
• Direct integration with VirtualGL, which allows users to easily run compositing window managers with 3D hardware acceleration
• Built-in SIMD-accelerated zlib implementation, which improves the performance of Tight encoding significantly on SSE2-equipped CPUs
• The TurboVNC Session Manager, which allows a user to remotely start a TurboVNC session on the TurboVNC host or to seamlessly and securely connect to, remotely kill, or generate a new one-time password for any TurboVNC session running under their account on the host
• Built-in SSH client with support for OpenSSH config files and password-less public key authentication (using ssh-agent or Pageant)
• Seamless integration with noVNC
  • The TurboVNC Server has built-in support for WebSockets, so a WebSockets proxy is not needed.
  • The TurboVNC Server optionally starts a simple web server to serve up noVNC and prints a URL that can be used to connect to the TurboVNC session.
• The TurboVNC Viewer can initiate connections to multiple VNC servers simultaneously, as well as tile multiple connection windows.
• The TurboVNC Viewer maintains a different set of options for each unique TurboVNC host.

Note that we do not track the development of TigerVNC very closely, so if you feel that any part of this comparison is erroneous, please contact the TurboVNC maintainer.

TigerVNC

• 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 with libvncserver 0.9.9 or later, which uses the TurboVNC encoder.
• Native language support
• Multi-threaded Tight decoding (investigating, but the feature in general is something of a mixed bag)
• Alpha-channel-enabled remote cursors

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 X.org infrastructure from source, 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. 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.

Performance

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, and assuming a Windows or Linux client. The TigerVNC Viewer currently suffers from a severe performance loss on macOS, due to unknown reasons.) The following table lists equivalent settings between the two solutions:

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.