Processed through Paypal
No account required.
Donate Bitcoin to this wallet:
Donate Ethereum to this wallet:
Donate Litecoin to this wallet:
|File - Download TurboVNC v2.2.2 (Win32)|
Always scroll to the bottom of the page to download files on OlderGeeks.com.
We don't believe in fake/misleading download buttons and tricks.
TurboVNC v2.2.2 (Win32)
TurboVNC is a derivative of VNC (Virtual Network Computing) that is tuned to provide peak performance for 3D and video workloads. TurboVNC was originally a fork of TightVNC 1.3.x, and on the surface, the X server and Windows viewer still behave similarly to their parents. However, the current version of TurboVNC contains a much more modern X server code base (based on X.org 7.7) and a variety of other features and fixes not present in TightVNC, including a high-performance Java viewer. In addition, TurboVNC compresses 3D and video workloads significantly better than the “tightest” compression mode in TightVNC 1.3.x while using only typically 15-20% of the CPU time of the latter. Using non-default settings, TurboVNC can also match the best compression ratios produced by TightVNC 1.3.x for 2D workloads. Furthermore, TurboVNC contains some unique features that are designed specifically for visualization applications.
All VNC implementations, including TurboVNC, use the RFB (remote framebuffer) protocol to send “framebuffer updates” from the VNC server to any connected "viewers." Each framebuffer update can contain multiple "rectangles" (regions that have changed since the last update.) As with TightVNC, TurboVNC analyzes each rectangle, splits it into multiple "subrectangles", and attempts to encode each subrectangle using the "subencoding type" that will provide the most efficient compression, given the number of unique colors in the subrectangle. The process by which TurboVNC does this is referred to as an "encoding method." A rectangle is first analyzed to determine if any significant portion of it is solid, and if so, that portion is encoded as a bounding box and a fill color ("Solid subencoding.") Of the remaining subrectangles, those with only two colors are encoded as a 1-bit-per-pixel bitmap with a 2-color palette ("Mono subencoding"), those with low numbers of unique colors are encoded as a color palette and an 8-bit-per-pixel bitmap ("Indexed color subencoding"), and subrectangles with high numbers of unique colors are encoded using either JPEG or arrays of RGB pixels ("Raw subencoding"), depending on the encoding method. zlib can optionally be used to compress the indexed color, mono and raw subrectangles.
Part of TurboVNC's speedup comes from the use of libjpeg-turbo. However, TurboVNC also eliminates the CPU-hungry smoothness detection routines that TightVNC 1.3.x used to determine whether a subrectangle is a good candidate for JPEG compression, and TurboVNC's encoding methods tend to favor the use of JPEG more, since it is now generally the fastest subencoding type. Furthermore, TurboVNC eliminates buffer copies, it maximizes network efficiency by splitting framebuffer updates into relatively large subrectangles, and it uses only the zlib compression levels that can be shown to have a measurable performance benefit.
TurboVNC is the product of extensive research, in which many different permutations of the TightVNC encoder were benchmarked at the low level against a variety of captured RFB sessions that simulate real-world application workloads, both 2D and 3D. TurboVNC's encoding methods have been adopted by TigerVNC and libvncserver.
In addition to high performance, other notable features of TurboVNC include:
Fine-grained control over the JPEG image quality and the level of chrominance subsampling
Double buffering on the client side to reduce tearing artifacts in 3D and video applications
Flexible and configurable full-screen/multi-screen support
Full support for IPv6
Advanced flow control and continuous updates. This allows clients to receive framebuffer updates without specifically requesting them, which can improve performance dramatically on high-latency connections.
Authentication with one-time passwords or Unix login credentials. Access control lists can be used to share VNC sessions with only certain users.
TurboVNC allows security/authentication policies to be set globally for a particular server machine.
Multithreaded Tight encoding
"Lossless refresh" allows a viewer to request a lossless copy of the current screen image. This is useful in situations in which image quality is critical but the network is too slow to support sending a high-quality image for every frame. Lossless refreshes can be performed manually when a certain hotkey is pressed, or the TurboVNC Server can be configured to send a lossless refresh automatically if the user stops interacting with the application for a certain period of time.
A high-performance Java viewer, deployable using Java Web Start. This viewer is based on the TigerVNC Java viewer but has numerous additional features, the most notable of which is the ability to accelerate JPEG decompression by calling libjpeg-turbo through JNI. This gives the Java TurboVNC Viewer similar levels of performance to the native TurboVNC Viewer.
TurboVNC, when used with VirtualGL, provides a highly performant and robust solution for remotely displaying 3D applications over all types of networks.
On "modern" hardware, TurboVNC is capable of streaming 50+ Megapixels/second over a 100 Megabit/second local area network with perceptually lossless image quality. TurboVNC can stream between 10 and 12 Megapixels/second over a 5 Megabit/second broadband connection at reduced (but usable) image quality.
TurboVNC is compatible with other VNC distributions, particularly with those that also support Tight encoding (such as TigerVNC, TightVNC, and UltraVNC.)
Significant changes relative to 2.2.1:
Fixed an error ("javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)") that occurred when attempting to use any of the TLS* security types with the Java TurboVNC Viewer running under Java 7u211, 8u201, 11.0.2, or later.
Fixed an issue in the Java TurboVNC Viewer's built-in SSH client whereby values for the ServerAliveInterval keyword in the OpenSSH config file were interpreted as milliseconds rather than seconds. This caused the SSH connection to fail if the value specified for ServerAliveInterval was too low.
Fixed a regression introduced by 2.2.1 that caused constant flickering in the UltraVNC Viewer when it was used with the TurboVNC Server.
Fixed an issue in the TurboVNC Server whereby, if interframe comparison was enabled and the remote desktop was resized to a smaller size, the server would sometimes send a framebuffer update that exceeded the new desktop dimensions. This crashed the UltraVNC Viewer.
Fixed a denial-of-service (DoS) vulnerability in the TurboVNC Server that was exposed when many RFB connections were made to the server and never dropped, thus exceeding the Xvnc process's allotment of file descriptors. When this occurred, it triggered an infinite loop whereby the TurboVNC Server's listener socket handler returned immediately with an EMFILE ("Too many open files") error, but the handler continued to be called by the X.Org code because the incoming RFB connection never succeeded. This infinite loop prevented the TurboVNC session owner from launching any X11 programs in the session (since those require Unix domain socket connections) until one or more of the RFB connections dropped, and the continuous flood of error messages in the session log caused the log to grow by megabytes per second until all available disk space was exhausted. The TurboVNC Server now sets a reasonable RFB connection limit (which can be adjusted using a new Xvnc argument, -maxconnections) and rejects all new connections once this limit has been reached. The upper limit for -maxconnections should be low enough to avoid the aforementioned EMFILE error and infinite loop.
Fixed an issue in the Linux/Un*x TurboVNC Viewer whereby, if multiple buttons on an extended input device (such as a drawing tablet) were pressed or released in rapid succession, some of those button events could accidentally be discarded by the TurboVNC Helper under certain circumstances, leading to a loss of synchronization between the client's and the TurboVNC session's extended input device button state. From the point of view of applications running in the TurboVNC session, the extended input device buttons appeared to stick in the down or up position.
Click here to visit the author's website.
Continue below to download this file.
|234||426||turbovnc.org <img src="https://www.oldergeeks.com/downloads/gallery/thumbs/TurboVNC1_th.png"border="0">||Jun 14, 2019 - 11:22||2.2.2||2.17MB||EXE||, out of 1 Votes.|
|TurboVNC v2.2.2 (Win32)|
→→ Download Now ←← - Click to Rate File -
Like? Share this page on Twitter → Tweet