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.
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, 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.
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 OS X, 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.
|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 TurboVNC web site.|