[VirtualGL-Users] New milestone pre-release (1.2 alpha2) of TurboVNC is available

[DRC <dco...@us...>]

http://virtualgl.sourceforge.net/vnc.nightly/

Quite a few bug fixes, as well as a tremendous amount of work on the 
Java viewer (thanks Brian!)  Thanks also to our benevolent benefactor, 
Santos Ltd, for sponsoring this effort.  The Java viewer is now feature 
complete and contains a lot of new goodies since the last milestone 
pre-release, including a lot better performance.  All known issues with 
it are documented in the Bug tracker.  We weren't able to get it to 
perform quite at native levels-- in the aggregate, it's about a 70-80% 
solution when used with the libjpeg-turbo JNI library-- but it's still a 
vast improvement over the TurboVNC 1.1 and TigerVNC Java viewers.  It 
begins to approach the level of performance that would be useful for 
day-to-day 3D work.  Heck, it's still faster than a lot of native VNC 
viewers out there.  Also, that additional 30% is only going to be 
noticeable on a high-speed network where the CPU is the primary 
bottleneck.  For those who can sacrifice that performance, the new Java 
viewer provides a tremendously friendlier GUI on Mac and Unix, as well 
as support for VeNCrypt (if used with a TigerVNC server) and desktop 
resize (currently requires TigerVNC server or a Windows VNC server, but 
we're working on this for the TurboVNC Server as well.)  Feature-wise, 
there is little that the native viewers can do that the new Java viewer 
can't.  One of the only major features it lacks is support for grabbing 
the keyboard (because this would have to be accomplished through JNI, 
which is somewhat messy.)

A reminder that you need the pre-release build of the libjpeg-turbo 1.3 
SDK to take advantage of the JPEG acceleration support: 
http://www.libjpeg-turbo.org/DeveloperInfo/PreReleases.  We have also 
discovered that running the JVM with the -server option improves 
performance significantly.  Neither of these things are necessary when 
using the Mac app, however, since it embeds the JNI library into its app 
bundle and automatically passes -server to the JVM.

Since the new Java viewer is written in Swing, it should be possible to 
use it with AjaxSwing (http://www.creamtec.com/products/ajaxswing/) to 
translate the viewer into HTML 5 for display to mobile devices.  I 
haven't personally tried that, though.

This pre-release also contains a completed implementation of the RFB 
flow control extensions (Continuous Updates and Fence), ported from 
TigerVNC.  Thanks to Altair Engineering, Inc. for funding this effort. 
These extensions allow the TurboVNC Server to stream updates 
continuously to the viewer without having to wait for it to request 
updates explicitly, thus preventing the frame rate from being capped at 
1 / (round-trip time).  As a for instance, on a 10 Mbit, 200 ms network, 
low-quality JPEG is now able to stream at ~20 Mpixels/sec 
(bandwidth-limited) instead of ~5 Mpixels/sec (latency-limited) for a 
1-megapixel remote desktop.

Some notes about the flow control extensions:

-- The faster the network, the more time the Linux congestion control 
algorithm (Vegas) can take to "warm up".  Since the RFB flow control 
extensions attempt to keep pace with Vegas, they can also take a while 
to warm up under those circumstances, which can make it appear as if 
they aren't working when you first start dragging the mouse.  On a 
fairly low-bandwidth network (10 Mbit, for instance), this shouldn't be 
an issue, but on long-haul fibre, it might be noticeable.

-- All of the viewers have a hidden command-line switch (-nocu) that 
allows you to disable the flow control extensions altogether and revert 
to the TurboVNC 1.1 behavior.  This can also be accomplished by setting 
"continuousupdates=0" in the .vnc connection info file.  Note that, due 
to the way the Windows viewer automatically saves the options for a 
particular host, once you specify -nocu, continuous updates will be 
disabled until you start the viewer with -cu to re-enable it.  It also 
goes without saying that the flow control extensions won't be enabled if 
you use an older TurboVNC viewer or server on one end of the connection. 
  They should, however, be 100% compatible with TigerVNC 1.2.

-- On the server end, you can pass an argument of -noflowcontrol to 
vncserver to emulate the behavior of the experimental (pre-flow-control) 
Continuous Updates feature that didn't make it into 1.1.

-- Some have asked about the possibility of completely disabling any 
kind of "update spoiling" in TurboVNC.  That can now be accomplished by 
starting the server with -noflowcontrol -deferupdate 0.  This will 
ensure that all updates are passed to the viewer, assuming the viewer 
supports the flow control extensions.  It will perform rather poorly if 
the updates being sent are small (such as typing in a console), but 
medical viz folks were interested in having a solution that could 
guarantee delivery of every pixel from server to client.  This should do 
it, unless I miss my guess.


Remaining funded features to be developed for 1.2:
-- Desktop resize support
-- Interframe differencing option


Remaining unfunded features that would be nice to have for 1.2:
-- Improved SSH support in the Java viewer (private key support, GUI 
integration)
-- SSH integration in the Windows viewer (-via and -tunnel options 
similar to the X11 viewer, as well as a GUI to specify the SSH server)
-- Re-working the embedded HTTP server in Xvnc so that it serves up the 
Java viewer using JavaWebStart


I have cleaned up, documented, and checked in the scripts that I have 
been using to generate "official" TurboVNC project binaries.

svn co 
https://virtualgl.svn.sourceforge.net/svnroot/virtualgl/vnc/buildscripts 
buildscripts

fetches them, or you can browse them at:

http://virtualgl.svn.sourceforge.net/viewvc/virtualgl/vnc/buildscripts/


Share and enjoy!