VirtualGL

In case of an X11 connection some client-side VirtualGL software is also needed to receive the rendered graphics output separately from the X11 stream.

The performance of OpenGL applications can be greatly improved by rendering the graphics on dedicated hardware accelerators that are typically present in a GPU.

Indirect rendering uses the GLX extension to the X Window System ("X11" or "X") to encapsulate the OpenGL commands inside of the X11 protocol stream and ship them from an application to an X display.

The GLX commands are used to bind OpenGL rendering contexts to a particular X window, obtain a list of pixel formats that the X display supports, etc.

In the process of rewriting the GLX calls, VirtualGL also redirects the OpenGL rendering into off-screen pixel buffers ("Pbuffers.")

Since VirtualGL is redirecting the GLX commands away from the 2D X Server, it can be used to add accelerated 3D support to X proxies (such as VNC) as well as to prevent indirect OpenGL rendering from occurring when using a remote X display.

3D applications, on the other hand, generate images with fine-grained, complex color patterns and much less correlation between subsequent frames.

VirtualGL works around this problem in two ways: TurboVNC and TigerVNC are offshoots of TightVNC that accelerate the Tight and JPEG encoding, in part by using libjpeg-turbo, a SIMD-accelerated version of libjpeg.

TurboVNC includes further optimizations that allow it to display 10–12 Megapixels/second over a 5 Megabit broadband link, with noticeably less but usable image quality.

TurboVNC also extends TightVNC to include client-side double buffering and other features targeted at 3D applications, such as the ability to send a lossless copy of the screen image during periods of inactivity.

TigerVNC is a more recent fork of TightVNC that provides similar performance to TurboVNC in most cases but has different project goals and features.

Meanwhile, the non-OpenGL elements of the application's display are sent over the network using the standard remote X11 protocol and rendered on the client machine.

Additionally, the VGL Transport does not inherently support collaboration (multiple clients per session), since the images are being pushed to the users' machines rather than being pulled.

When using the X11 Transport with an X proxy, both the 3D and 2D rendering occur on the application server. VirtualGL reroutes the 3D commands from the application to the 3D accelerator hardware, reads back the rendered images, and draws them as a series of uncompressed bitmaps into the X proxy (VNC or a similar system.) Meanwhile, the 2D drawing commands (X11 commands) from the application are sent to the X proxy directly. The X proxy is solely responsible for compressing the images and sending them to remote clients.
When using the VGL Transport, the 3D rendering occurs on the application server, but the 2D rendering occurs on the client machine. VirtualGL compresses the rendered images from the 3D application and sends them as a video stream to the client, which decompresses and displays the video stream in real time.