Download turbovnc

Thanks for downloading TurboVNC 3.0.3 Download of TurboVNC 3.0.3 will start in 5 seconds... Problems with the download? Please restart the download. TurboVNC 3.0.3 File Name: turbovnc-3.0.3.x86_64.rpm File Size: 39.47 MB Date Added: August 18, 2023 PriceFree Version3.0.3 Release DateFebruary 27, 2023 PublisherTurboVNC - Publisher's DescriptionTurboVNC is a high-performance, enterprise-quality version of VNC based on TightVNC, TigerVNC, and X.org. It contains a variant of Tight encoding that is tuned for maximum performance and compression with 3D applications (VirtualGL), video, and other image-intensive workloads. TurboVNC, in combination with VirtualGL, provides a complete solution for remotely displaying 3D applications with interactive performance. TurboVNC's high-speed encoding methods have been adopted by TigerVNC and libvncserver, and TurboVNC is also compatible with any other TightVNC derivative.TurboVNC forked from TightVNC in 2004 and still covers all of the TightVNC 1.3.x features, but TurboVNC contains numerous feature enhancements and bug fixes relative to TightVNC, and it compresses 3D and video workloads much better than TightVNC while using generally only 5-20% of the CPU time of the latter. Using non-default settings, TurboVNC can also be made to compress 2D workloads as "tightly" as TightVNC.Features Fine-grained control over the JPEG image quality and 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 (greatly improves performance on high-latency connections) Authentication with one-time passwords or Unix login credentials (in addition to standard VNC passwords) Access control lists (for sharing VNC sessions with only certain users) Allows security/authentication policies to be set globally for a particular server machine Multithreaded encoding “Lossless refresh” allows a viewer to request a lossless copy of the current screen image, either manually or automatically (after a specified number of seconds of inactivity) High-performance zero-install Java viewer, deployable using Java Web Start, that calls libjpeg-turbo through JNI to achieve native levels of performance Fastest VNC viewer available (that we know of) on OS X and Windows

VirtualGL will only have a limited pool of PBOs (no more than 3) to work with. This is awkward at best, since the TurboVNC Server doesn't necessarily generate a framebuffer update immediately when VirtualGL draws a frame. The VNC server basically acts as another layer of frame spoiling, since it can coalesce multiple frames from VirtualGL into one framebuffer update as a result of the deferred update timer or as a result of the RFB flow control extensions (which prevent updates from being sent faster than the network or viewer can handle them.) At first glance, it might seem possible to make the proposed PBO PutImage extension asynchronous and thereby essentially treat the TurboVNC Server as VirtualGL's image transport thread. In other words, VirtualGL would, within the application rendering thread, use the PBO PutImage extension to request a free PBO from the pool, and TurboVNC would block on that request until a PBO is free, then VirtualGL would fill the PBO with pixels and send back another request notifying TurboVNC that the PBO is ready to transmit. However, that scheme is likely not possible due to the fact that the TurboVNC Server is single-threaded (as are all X servers.) It will probably be necessary for the TurboVNC Server to pre-compress the H.264 pixels within the body of the PBO PutImage function and then to just store those pixels in a holding buffer until the next RFB framebuffer update.Approach #3 seems to be the most promising, but I suspect it would take hundreds of hours of labor to make it happen, and in the grand scheme of things, it may make more sense to wait for Wayland, since Wayland's architecture is much more conducive to the use of frame-based codecs such as H.264 (refer to #18) and probably GPU-based encoding as well. Furthermore, referring to the article on TurboVNC.org, H.264 doesn't necessarily benefit all types of applications. It is clear that it can benefit applications like video players, Google Earth, games, etc., but for ordinary CAD applications, the jury is still out.There are additional challenges inherent with decoding the H.264 stream with reasonable performance. As with JPEG, it would likely be necessary to use some sort of H.264 decoder accessed through JNI in the Java viewers, or perhaps to leverage the built-in decoders on some GPUs (if available.)

Efficiency and the need to encode at a fixed frame rate, because it is assumed that-- at least with double-buffered OpenGL applications-- each frame sent through VirtualGL will share few pixels with the previous frame (but, in some cases, the differences will be within the scope of H.264's predictive abilities.)Encoding the video stream is easy, because the pixels are already on the GPU. VirtualGL would simply encode them using NvENC or similar and transmit the H.264 stream directly from GPU memory. But that's where things get dicey. How would we transmit the stream through the TurboVNC Server and to the client? We could implement some sort of "compressed PutImage extension", whereby the compressed stream could be passed through unmodified by the TurboVNC Server and decompressed by the viewer, but this introduces all-new problems:How would we handle window overlapping? The hypothetical compressed PutImage extension would have to communicate the structure of an overlapped window image back to VirtualGL so that it could break the image down into component rectangles and send each separately, or perhaps we could just make the simplifying assumption that, if the window is overlapped or obscured, H.264 will be temporarily disabled for that window.How would we handle combined OpenGL and X operations? An OpenGL/X11 application is well within its rights to request a copy of the OpenGL-rendered pixels using X11 functions (XGetImage(), for instance), assuming that it has called glXWaitGL() to ensure that the pixels have been delivered to the X server. So how would the TurboVNC Server accommodate that request if the OpenGL-rendered pixels are being passed through as an encoded H.264 stream. It would have to keep a copy of the video stream all the way back to the last I-frame, or it would have to somehow notify VirtualGL that it needs an uncompressed copy of the current frame (problematic, since VirtualGL may not have it anymore), or VirtualGL would have to deliver two copies of the frame to the X server-- one compressed and one uncompressed. Delivering two copies isn't a huge deal, since the current VirtualGL/TurboVNC solution already delivers an uncompressed version of the frame. The increase in bus usage would be only incremental, due to the addition of delivering the compressed H.264 version of the frame.How would we ensure that the viewer can handle H.264? This is normally negotiated by the VNC server, and since it has access to all of the