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! ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
