TurboVNC 3.1.2

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

Tags c vnc rdp remote-desktop 3d tightvnc cross-platform java
License GNU GPL
State stable

Recent Releases

3.1.201 Jul 2024 09:25 minor feature: ### Significant changes relative to 3.1.1: 1. The TurboVNC Server now assigns an ordinal ID to every VNC viewer after the. Viewer successfully connects, and the viewer's ID is reported in the TurboVNC Session log along with the IP address from which the viewer connection Originated. This makes it easier to distinguish log entries related to a Specific viewer, especially when using SSH tunneling (which makes it appear as if all viewer connections originate from the loopback IP address.) The TurboVNC Server now also logs the total number of simultaneously connected Viewers.
3.1.123 Apr 2024 16:16 minor feature: 1. By default, each instance of the Linux TurboVNC Server now listens on the abstract Unix domain socket, in addition to the pathname Unix domain socket (under **/tmp/.X11-unix**), associated with its X display number. Thisprevents recent versions of GDM, when configured with `WaylandEnable=false`, from attempting to use Display :1 for the local session if a TurboVNC session is already using Display :1. The previous behavior can be restored by passing `-nolisten local` to `vncserver` or adding `-nolisten local` to the ` serverArgs` variable in **turbovncserver.conf**. 2. The `vncserver` script now checks whether the abstract Unix domain socket associated with an X display number is in use before assuming that the display number is available. 3. Fixed an issue in the Windows TurboVNC Viewer whereby an F10 key press, followed by an F10 key release, caused the keyboard focus to be redirected to the system menu, and subsequent keystrokes were consumed by the system menu until F10, left Alt, or Esc was pressed to dismiss the menu. 4. Fixed an issue whereby GTK applications (including the GNOME window manager) running in a TurboVNC session attempted to display to a local Wayland session if one was active.
2.008 May 2015 01:45 major security: 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 feature: 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 major feature: 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 properly. 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 viewer instance. 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 decompression. 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 viewer. The Java TurboVNC Viewer can now be used to connect to UltraVNC Repeater instances. Refer to the documentation for the Via parameter for more details.