TurboVNC/turbovnc: a high speed VNC built for image heavy and 3D workloads

What VNC is, in the project's own words

The About section opens with a definition that is worth reading carefully, because it explains what the software does and, more importantly, what it does not.

Virtual Network Computing is a remote display system that allows you to view and interact with a desktop environment that is running on a remote computer. Using VNC, you can run graphical applications on a remote machine and send only the pixels generated by those applications to your local machine. VNC is platform independent and supports a wide variety of operating systems and architectures, as both servers and clients.

That last clause is the design constraint that follows from the first. VNC is a screen sharing protocol. It sends pixels, not commands, which means it works with any application, any window system and any display, with no client side agent to install and no requirement that the remote software know anything about the protocol.

The price of that portability is the reason TurboVNC exists. Sending raw or naively compressed pixels across a network is slow, and the whole art of VNC is in the encoding, in deciding what to send and what to leave out.

The Tight encoding variant is the project

TurboVNC is described as a high-speed version of VNC derived from TightVNC, and it contains a variant of the Tight encoding that is tuned to maximise performance for image-intensive applications, such as VirtualGL, video applications and image editors, while still providing excellent performance for other types of applications.

So the interesting engineering is in the codec, not in the transport or the desktop integration. The Tight encoding works by sending the pixels that changed and describing them in a compact form, and TurboVNC's contribution is a variant of that tuned for the cases where a large part of the frame is a photo, a video frame or a rendered image rather than mostly flat colour and text, which is what a general desktop session looks like.

That is a narrow focus, and it is the right one. A VNC implementation that is generally better at everything is a much harder project than one that is much better at the thing you actually need, and the project description makes the trade explicit by naming the workloads it targets.

The combination is then described as the complete solution. TurboVNC, in combination with VirtualGL, provides a complete solution for remotely displaying 3D applications with interactive performance, which is the pairing that turns a remote framebuffer into something usable for visualisation work on a workstation.

The licensing is a long list, and it matters

The Legal section is longer than most READMEs of this size, and it is not boilerplate.

The project's own copyright is a set of lines rather than one, with D. R. Commander for 2009 to 2026, Steffen Kieß for 2021, Brian P. Hinz for 2011 to 2019, the University Corporation for Atmospheric Research for 2010, Sun Microsystems for 2004 to 2008, and Landmark Graphics Corporation for 2004.

Then there is the inherited code, and the project names the sources. TurboVNC contains code from LibVNCServer, RealVNC, TigerVNC and TightVNC, each with its own copyright holders listed, including Pierre Ossman for Cendio AB, Martin Koegler, Joel Martin, Gernot Tenchio, the TigerVNC team, Red Hat, the TightVNC team, Constantin Kaplinsky, OCCAM Financial Technology, RealVNC Ltd, Cendio AB again, Sun Microsystems, Tridia Corp and AT&T Laboratories Cambridge.

The distribution terms are the GNU General Public Licence as published by the Free Software Foundation, with the file `LICENSE.txt` holding the conditions, and the note that TurboVNC also contains code from other sources, so you should see the individual source files for the details of the conditions under which that code is made available.

For anyone redistributing a build, that last sentence is the operative one. A TurboVNC binary carries GPL obligations and several upstream copyright lines, and the per file conditions are where the practical detail is.

Funding is part of the design

The README has a Funding section, and it is short enough to quote.

TurboVNC is an independent open source project, but the project relies on patronage and funded development in order to maintain that independence. The stated rationale is that the easiest way to ensure TurboVNC remains community focused and free of any one organization's agenda is to sponsor the project through GitHub, and that all the sponsorship money goes directly toward funding the labor necessary to maintain TurboVNC, support the user community, and implement bug fixes and strategically important features.

That is an unusual argument to make in a README and a reasonable one. VNC implementations tend to be maintained by whoever needs them, and an implementation that is quietly steering towards one organisation's priorities is a real risk for a protocol that many vendors depend on. Saying so in the README, and asking for money rather than for feature requests, is a way of keeping that risk visible.

It also tells you what to expect from the project in practical terms. The list of what the money pays for is a maintenance list, not a feature list, which is a good sign for a codebase that has been stable and portable for a long time, and a modest sign for a roadmap.

The repository layout

The top level of the repository is a conventional split for a project with two client implementations and a shared core.

There is `unix/` and `win/` for the platform specific code, `common/` for the shared pieces, `java/` for the Java viewer, `doc/` for documentation, `release/` for packaging material, `cmakescripts/` for the build system helper modules.

The build is CMake based, with a `CMakeLists.txt` at the root and a `BUILDING.md` document for the build instructions, and a `ChangeLog.md` for the history. The `java/` directory is worth noting, because a Java viewer means the protocol can be consumed from a stack that is not C, which is a portability decision that a lot of remote display projects skip.

The releases are numbered with a patch level that has moved on from the old 3.2 series, with 3.3beta2 in December 2025, 3.3 in February 2026 and 3.3.1 in August 2026, and the last push to the repository was on 2026-10-08 with the repository not archived.

Where this is the wrong tool

The first wrong case is a general remote administration session. VNC gives you pixels, and the protocol does not include the session handling that people expect from a modern remote desktop tool. If what you need is to support a colleague's desktop, this is the wrong protocol.

The second is a bandwidth constrained link with a mostly textual workload. The whole project is tuned for image heavy frames, so the case where VNC's traditional advantages, low CPU, small client, broad platform support, matter more than frame rate for a terminal session over a slow link is not where TurboVNC improves on the alternatives.

The third is a deployment that cannot run X11 on the remote side. TurboVNC is a server for an X server, so the remote machine has to have a display, which excludes the headless Linux boxes that a lot of tools now assume.

The fourth is a hardware accelerated 3D pipeline. The pairing is what the project highlights, but it means the client has to support the graphics hardware and the software stack has to match on both sides, and the performance story changes completely if you have a modern remote protocol with its own 3D acceleration path.

On the state of the project, the release line is steady at 3.3 with a 3.3.1 patch in August 2026, the licence is GPL-2.0, the code is C, and the project asks for sponsorship rather than corporate direction, which for a foundational piece of remote display infrastructure is a reasonable governance model and a small one.

Editorial conclusion

Adopt TurboVNC when you need to see a graphical application on a remote machine and the default remote display protocol is too slow for the workload, especially for 3D rendering through VirtualGL, video or image editing, where the encoding work is what the whole project exists to do. Do not adopt it where a modern remote desktop protocol with clipboard and file transfer support matters more than frame rate, since VNC sends pixels and the protocol predates most of what a user expects from a remote session. Verify first that the platform you need is covered by the unix and win trees in the repository, that your VirtualGL installation matches the TurboVNC version you deploy, and that you read the licensing section, because the code carries GPL terms and copyright from several upstream projects that you inherit when you redistribute it.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. TurboVNC/turbovnc on GitHub