TurboVNC is a performance-oriented version of the VNC remote desktop
connection protocol, based on TightVNC, x4vnc, TigerVNC, and X.org.
It provides 3D rendering and VirtualGL compression, works well on video-
and image-intensive connections. It remains fully compatible to other
implementations, but often requires less than a fifth processing power.
A Java-based VNC viewer is also available
2.008 May 2015 01:45
A new security configuration file directive (no-httpd) has been introduced in
order to allow the built-in HTTP server in the TurboVNC Server to be disabled
on a system-wide basis.
The TurboVNC X server has been completely overhauled and is now based on the
unmodified Xorg 7.7 code base. This overhaul enables support for the X
extensions needed by newer window managers (RANDR 1.2, Composite, XFIXES,
Damage, etc.) In addition, the keyboard handler has been completely overhauled
and now uses the XKEYBOARD extension. This fixes key mapping issues that
occurred when running TurboVNC with certain versions of Gnome (previously, it
was necessary to set an environment variable in xstartup.turbovnc to work
around those issues.)
Added the ability to dynamically resize the remote desktop, either through the
X RANDR extension on the server or remotely from a VNC client that supports the
RFB desktop size extensions. Both TurboVNC viewers now also include an
"automatic desktop resize" feature that will resize the remote desktop so.
that it always fits exactly in the viewer window without using scrollbars. A
new "max-desktop-size" directive is provided in the TurboVNC security
configuration file in order to allow a maximum desktop size to be specified for
all TurboVNC sessions on a given server machine.
The X11 TurboVNC Viewer has been retired and replaced with the Java TurboVNC
Viewer. The X11 viewer will continue to be maintained in the 1.2.x branch on
a break/fix basis only. The Java viewer provides similar performance to the
X11 viewer when remotely displaying 3D application workloads to a reasonably
modern client machine.
The Java TurboVNC Viewer, when run as an applet, can now be displayed to an
embedded frame in a web page rather than a dedicated window. This restores a
feature of the TurboVNC 1.1 Java viewer that was lost in 1.2. Full-screen
mode and scaling do not work when the viewer is run as an embedded applet.
vncconnect now uses the VNC X extension to e
1.2.328 Feb 2015 19:15
Fixed an issue whereby the Java TurboVNC Viewer would not enable the OS X Lion
full-screen mode feature on OS X 10.10 "Yosemite".
Fixed a regression introduced in 1.2.2 that caused a non-fatal
NullPointerException in the Java TurboVNC Viewer whenever the scaling factor
was changed in the options dialog.
Fixed an issue in the Java TurboVNC Viewer whereby the toolbar would sometimes
appear all black or be overwritten by the initial framebuffer update when
running under Java 1.7 and later.
Fixed an issue whereby the Java TurboVNC Viewer would unnecessarily add
scrollbars to the viewer window if the remote desktop was exactly large enough
to fit in the window without using scrollbars.
Fixed an issue whereby the /grabkeyboard, /scale, and /span command-line
parameters to the Windows TurboVNC Viewer could not be specified in uppercase.
The Windows TurboVNC Viewer now supports scaling factors 200.
Java 1.7 and later on Mac platforms no longer include a hardware-accelerated 2D
blitter for Java 2D, opting instead to use only OpenGL for image drawing. When
using the default pixel format , this is incredibly slow on some Macs,
because the OpenGL blitter is having to set all of the alpha values to 255
Thus, the Java TurboVNC Viewer will now automatically use an
alpha-enabled pixel format for its back buffer if it detects that it is
running on a Mac with Java 1.7 or later This improves
drawing performance by as much as 4-5x on certain Mac models, although the
drawing performance with Apple Java 1.6 is still going to be faster than with
Java 1.7 or later. The Java TurboVNC Viewer will also now automatically use an
alpha-enabled pixel format on non-Mac platforms if it detects that OpenGL Java
2D blitting is being selected
The "turbovnc.forcealpha" Java system property can be used to override the
default behavior described above
Normally, Java 2D uses Direct3D by default for blitting on
Windows platforms, but GDI blitting is almost always faster Thus, the Java TurboVNC
1.2.231 Oct 2014 07:05
The Xvnc build system now uses CMake.
Xvnc can now be built and run successfully on OS X and PowerPC platforms.
The default DPI of the X server has been changed to 96, to match that of
recent X.org releases and other VNC implementations.
When the server is run with a depth of 8, PseudoColor visuals now work
Added a security option to the Java TurboVNC Viewer that, when enabled,
will prevent the user from opening any new VNC connections from within the same
The libjpeg-turbo JNI libraries are now deployed with the Java TurboVNC
Viewer on Un*x and Windows, so it is no longer necessary to install the
libjpeg-turbo SDK on those platforms in order to get accelerated JPEG
Fixed a couple of cosmetic issues with the automatic lossless refresh feature.
The Mac packaging system now uses pkgbuild and productbuild rather than PackageMaker.
Fixed various usability issues related to the display of dialogs in the Java TurboVNC Viewer.
If the TurboVNC Server receives a clipboard update larger than 1 MB from a
connected viewer, it will now ignore the update instead of disconnecting the
The Java TurboVNC Viewer can now be used to connect to UltraVNC Repeater
instances. Refer to the documentation for the Via parameter for more