TurboVNC | About / 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 code base. Throughout 2010 and 2011, The VirtualGL Project contributed many hours of labor (probably half of them pro bono) to the development of TigerVNC, in the hope of rebasing TurboVNC on the TigerVNC code base. That labor included porting most of TurboVNC’s Tight encoding optimizations into TigerVNC. However, it ultimately 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. Thus, with the release of TigerVNC 1.2.0 in 2012, The VirtualGL Project stepped down as a contributor and supporter of TigerVNC in order to focus on moving TurboVNC forward.

TurboVNC has always been focused on maximum performance for 3D and video applications, whereas TigerVNC was originally intended to be a more general-purpose solution. With TigerVNC 1.8, however, the TigerVNC developers started introducing features that seemed primarily intended to horn in on TurboVNC’s user base, so I wrote the original version of this article as a defensive position. It previously discussed key features that differ between TurboVNC and TigerVNC, but since the projects have rapidly evolved in different directions in the years since, that information was sorely outdated. (A list of notable TurboVNC features, some of which TigerVNC also supports, can be found here.) It is more instructive to discuss the underlying clash of project management styles, necessitated by different funding models and focuses, that prevented and still prevents The VirtualGL Project from officially supporting or recommending TigerVNC. This article is not intended as a critique against TigerVNC. Rather, it is meant to explain why our project diverged from that project and why the two projects will probably never converge again.

If TigerVNC is more to your liking, then by all means, use TigerVNC. If one of the plethora of other X proxies, such as FreeNX or Xpra, is more to your liking, then use that instead. However, TurboVNC has some strengths that those other solutions lack, and it doesn't make sense for people to struggle to fit the same square peg into the same round hole when a square hole exists and is actively supported.

Project Management and Funding

TigerVNC is primarily developed by Cendio, a Swedish company that uses TigerVNC as the open source core of its proprietary ThinLinc product. ThinLinc wraps TigerVNC with closed-source glue-ware that implements certain features, including one-time password support and session management, that are not available in TigerVNC. Basically, the funding to develop TigerVNC primarily derives from a business model that depends on keeping some key features out of TigerVNC.

TurboVNC has been developed independently since 2009 and is funded exclusively through patronage (ongoing individual and corporate donations to the TurboVNC General Fund) and funded development (financial support for the labor necessary to implement specific features and fixes.) Thus, our open source product is our only product, and that product must compete with proprietary products. That means that I must include enterprise-quality documentation in TurboVNC, provide enterprise-quality support for TurboVNC (often at no charge to individual users), ensure that TurboVNC is easy to build and straightforward to maintain, ensure that TurboVNC is as user-friendly and user-proof as possible, ensure that its benchmarking and regression testing procedures are documented and transparent, and design new TurboVNC features with a painful amount of caution and an eye toward community engagement (since TurboVNC has no testing, marketing/sales, or support teams.) TurboVNC's value proposition is that, if it doesn't cover a particular enterprise use case, then it is less expensive for an organization to fund the labor necessary to support that use case than it is for the organization to pay ongoing license fees for a proprietary product. However, that value proposition depends upon maintaining TurboVNC in a constant state of enterprise readiness.

Since TurboVNC has no sales or direct support revenue, there is no reliable income stream to reinvest into new feature development. I have to constantly hustle for funding to implement strategically important new features. If funding doesn’t emerge in a timely manner, then I sometimes have to implement new features speculatively, in the hope of growing the user base and thus increasing the pool of potential patrons and paying customers. Any labor that isn't specifically funded, including bug fixes and general project maintenance and community support and speculative feature development, has to be compensated using the limited TurboVNC General Fund. Once that fund runs out, any further labor that is needed to keep the project running and moving forward will be uncompensated. That necessitates a very strong “if it ain’t broke, don’t fix it” mentality, since there may not be funding to fix something I break.

The business model necessitated by independent open source development is fundamentally at odds with the business model that drives the development of TigerVNC. Because of its more reliable revenue stream and corporate R&D/support infrastructure, TigerVNC can get away with a lot of things as a project that I cannot get away with as an independent open source developer. That includes such things as refactoring whole subsystems purely for the sake of refactoring them (which has, on more than one occasion, caused a performance regression in TigerVNC.) No one is going to pay me to reorganize the code or do anything else that improves maintainability but has no visible benefit to end users. That type of work would have to be compensated using the TurboVNC General Fund, which only covers about 2-3 full work days of labor per month (usually closer to 2, unless I borrow from the VirtualGL General Fund), or not compensated at all. Bug fixes, general project maintenance, and a number of other things that are more important than code refactoring also have to be compensated using that fund. Thus, even if I rebased TurboVNC on the TigerVNC code base, it is likely that the projects would quickly diverge again, since my business model precludes me from staying abreast of the rapid pace of TigerVNC development. At the end of the day, I can only survive as an independent open source developer by having an extremely efficient and streamlined development process, and that necessitates using a code base with which I am intimately familiar (as well as carefully managing changes to that code base.)

Focus

When VirtualGL was first released in 2004, it was mostly a bolt-on technology for remote X, implementing server-side GPU-accelerated OpenGL rendering while allowing 2D rendering to pass through to a client-side X display. TurboVNC was originally just a quick & dirty means of using VirtualGL on high-latency/low-bandwidth networks that were not suitable for remote X. For years, TurboVNC was little more than TightVNC v1.3.x with Tight encoding optimizations that favored the use of high-speed JPEG, thus providing “interactive” frame rates for 3D and video workloads. As the industry evolved away from remote X, TurboVNC evolved into more of a Swiss Army Knife for creating large-scale on-demand remote display web portals for 3D applications. It is only in recent years that TurboVNC has facilitated more general-purpose use cases, although it is still exclusively focused on Un*x servers and primarily focused on 3D and video applications.

As mentioned above, TurboVNC's funding model necessitates a very strong "if it ain't broke, don't fix it" mentality, but it also necessitates a very strong "if it ain't very useful, don't support it" mentality. That means that, unlike TigerVNC, TurboVNC does not provide multiple VNC server and viewer code bases. (TigerVNC provides a Windows VNC server that receives little development attention, whereas UltraVNC and TightVNC are focused on Windows hosts and have much better usability and compatibility than the Windows TigerVNC Server. TigerVNC also provides a non-standalone Java VNC viewer, the sole purpose of which seems to be to support legacy Java Web Start deployments. TigerVNC also provides two different methods of attaching a VNC server to a physical X server.) Furthermore, TurboVNC de-emphasizes legacy RFB encodings, such as Hextile and ZRLE, that have proven to be less efficient and performant than TurboVNC’s optimized Tight encoding methods, and it does not support high zlib compression levels that increase CPU usage without providing significantly better compression. These are also reasons why, even if I rebased TurboVNC on the TigerVNC code base, it is likely that the projects would quickly diverge again.

The X Server

TigerVNC, owing to its RealVNC heritage, is really designed to be built against a distribution-supplied X server code base. 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 TigerVNC Server from source requires a distribution-specific procedure, which is typically undocumented and difficult for many developers to figure out. When The VirtualGL Project was actively contributing to TigerVNC, we attempted to work around those build difficulties by providing a standalone "cross-compatible" build of TigerVNC that was statically linked with all of its dependencies, but that was a royal pain to maintain. 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 the TurboVNC Server have to be addressed by us, not by the O/S distributor. 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. If an issue or limitation is encountered in one of TigerVNC’s dependencies, then the TigerVNC developers must engage the upstream project to patch the dependency, and they must engage the operating system distributors to include the patch. As an independent open source developer, I don’t usually have the luxury of waiting on that process. If I encounter an issue or limitation in one of TurboVNC’s dependencies, I usually have to work around it or maintain an in-tree fork of the dependency (at least until it is patched upstream and the patch propogates to all supported platforms.)

systemd

With TigerVNC 1.11, the developers abandoned the vncserver script that had traditionally been used to launch VNC sessions, opting instead to launch sessions using systemd. The justification for that was to fully support newer window managers, such as GNOME 3+, that rely upon certain systemd features. However, this had the following ramifications:

TigerVNC can no longer be used with non-systemd operating systems, such as FreeBSD.
It is no longer possible to start multiple simultaneous TigerVNC sessions (or a simultaneous TigerVNC and local session) under the same user account.
Display numbers for TigerVNC sessions must be assigned statically to user accounts by the system administrator.
TigerVNC sessions can only be started and stopped by system administrators (root or users with sudo access.) In my experience, that sometimes leads to hard-to-diagnose permissions issues, especially when using SELinux, that cause the TigerVNC Server to fail silently. (See above RE: things that TigerVNC can get away with that I can’t.)

In my testing, systemd-dependent window managers can still be supported with a vncserver script, provided that the window manager is launched using a session desktop file rather than the xinitrc script. In order to support multiple simultaneous sessions under the same user account, it is also necessary to create a unique D-Bus session bus instance for each VNC session. That can cause issues with certain technologies, such as Control Group v2, that rely on information passed from systemd using the systemd-provided D-Bus session bus instance. The issues can be worked around by using the systemd-provided D-Bus session bus instance in a VNC session rather than creating a unique D-Bus session bus instance, which subjects the VNC session to Limitation 2 above but not to the other limitations. Many TurboVNC users choose to use more traditional window managers, such as MATE or Xfce, that don’t need systemd, so it doesn’t make sense to impose the systemd limitations upon those window managers. The ThinLinc documentation suggests that its session manager works around Limitations 3 and 4 above, which is presumably a major value-add for the proprietary ThinLinc product vs. TigerVNC. If TigerVNC provided a way to work around those limitations as well, then this would be less of a sticking point.

The Code Itself

The TigerVNC Server code base, owing to its RealVNC heritage, is written in C++. I am generally a fan of that, but the RealVNC 4 server code base has way too many levels of abstraction between the X.org code and the RFB server code. (Some of those levels of abstraction are necessitated by supporting multiple VNC servers with the same base classes. See above RE: focus.) That makes the server code difficult to read, and it makes issues in the server difficult to diagnose. The TurboVNC Server code base, owing to its TightVNC v1.3.x heritage, is written in C but has many fewer levels of abstraction. That makes it a bit trickier to maintain, but it is also much more readable. Furthermore, the TurboVNC Server shares its lineage with LibVNCServer, which makes it straightforward to port features between LibVNCServer and TurboVNC.

As a matter of project philosophy, TigerVNC requires MinGW on Windows platforms. It cannot be built using Visual Studio, despite the fact that Visual Studio is the most popular (and the only officially supported) Windows compiler. As mentioned above, I cannot get away with being a purist regarding TurboVNC’s dependencies, and that applies to the compiler as well.

Primarily because of the need to support embedded systems with limited memory and disk space, the TigerVNC developers adopted FLTK as a GUI toolkit for the TigerVNC Viewer. The widgets in FLTK are, frankly, not very attractive, and the lightweight nature of FLTK has necessitated quite a few upstream patches and in-tree workarounds in order to implement certain TigerVNC Viewer features. Mostly for historical reasons, the TurboVNC Viewer uses Java as a GUI toolkit. In the early 2010s, the Java TurboVNC Viewer received a great deal of funding from companies that were interested in deploying it as a web applet or a Java Web Start app. Thus, the Java TurboVNC Viewer evolved to the point at which it encompassed all of the critical features and performance of the native TurboVNC Viewer code bases, and it made sense to phase out the native code bases in favor of the Java TurboVNC Viewer with a built-in JRE (which makes it a standalone application.) Since applets and Java Web Start are not supported anymore, there is no technical reason why the TurboVNC Viewer couldn't be refactored as a native application. However, see above RE: the fact that my business model necessitates a very strong “if it ain’t broke, don’t fix it” mentality. It would take a lot of labor to refactor the TurboVNC Viewer as a native application, and no one has thus far been willing to pay for that labor. (In addition to porting the TurboVNC Viewer base classes to C++ and rewriting the GUI code, it would be necessary to refactor the TurboVNC Viewer’s built-in SSH client so that it uses libssh rather than a heavily modified version of JSch. Also, I would probably want to use GTK rather than FLTK.)

Conclusion

Probably the most prominent feature differences between TurboVNC and TigerVNC involve the viewer, the TurboVNC Session Manager, and the method by which VNC sessions are launched on the host. There are many other, more minor, feature differences and usability differences between the two solutions, but it became impossible to maintain a timely list of those. A list of notable TurboVNC features can be found here, and the change log has a more comprehensive list. If TurboVNC doesn’t support a specific feature that you need, then I am almost always willing to implement that feature under a funded development contract.