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.
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.
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:
|All 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 VirtualGL web site.|