* Using VirtualGL with X Proxies Such as VNC
{anchor: X11_Proxy_Usage}

The VGL Transport is a good solution for using VirtualGL over a fast
network.  However, the VGL Transport is not generally suitable for high-latency
or low-bandwidth networks, due to its reliance on the X11 protocol to send the
non-3D elements of the 3D application's GUI.  The VGL Transport also
requires an X server to be running on the client machine, which makes it
generally more difficult to deploy and use, particularly on Windows clients.
VirtualGL can be used with an "X proxy" to overcome these limitations.  An X
proxy acts as a virtual X server, receiving X11 commands from the application
(and from VirtualGL), rendering the X11 commands into images, compressing the
resulting images, and sending the compressed images over the network to a
client or clients.  X proxies perform well on all types of networks, including
high-latency and low-bandwidth networks.  They often provide rudimentary
collaboration capabilities, allowing multiple clients to simultaneously view
the same X session and pass around control of the keyboard and mouse.  X
proxies are also stateless, meaning that the client can disconnect and
reconnect at will from any machine on the network, and the 3D application will
remain running on the server.

Since VirtualGL is sending rendered 3D images to the X proxy at a very fast
rate, the proxy must be able to compress the images very quickly in order to
keep up.  Unfortunately, however, most X proxies can't.  They simply aren't
designed to compress, with any degree of performance, the large and complex
images generated by 3D applications.  Therefore, the VirtualGL Project provides
an optimized X proxy called "TurboVNC", a variant of
[[http://www.tightvnc.com][TightVNC]] that is designed specifically to achieve
high levels of performance with 3D applications running in VirtualGL.  More
information about TurboVNC, including instructions for using it with VirtualGL,
can be found in the TurboVNC User's Guide.

[[http://www.tigervnc.com][TigerVNC]] is a next-generation VNC project based
on the RealVNC and Xorg code bases.  TigerVNC spun off from the TightVNC
project in early 2009, and it uses the same high-speed JPEG codec as VirtualGL
and TurboVNC ([[http://libjpeg-turbo.virtualgl.org][libjpeg-turbo]].)  Unlike
TurboVNC, TigerVNC is not specifically designed for 3D applications.
However, TigerVNC can, if properly configured, produce performance that is
sufficient for using VirtualGL.  TigerVNC is available in Fedora 11 or later.

Other solutions, such as RealVNC and NX, also work well with VirtualGL.
Generally, none of these other solutions will provide anywhere near the
performance of TurboVNC, but some of them have capabilities that TurboVNC lacks
(NX, for instance, can do seamless windows.)

** Using VirtualGL with an X Proxy on the Same Server
{anchor: X11_Proxy_Usage_Local}

The most common (and optimal) way to use VirtualGL with an X proxy is to set up
both on the same server.  This allows VirtualGL to send its rendered 3D images
to the X proxy through shared memory rather than sending them over a network.

#IMG: x11transport.png

With this configuration, you can usually invoke

#Verb: <<---
/opt/VirtualGL/bin/vglrun {application_executable_or_script}
---

from within an X proxy session, and it will "just work."  VirtualGL reads the
value of the ''DISPLAY'' environment variable to determine whether to enable
the X11 Transport by default.  If ''DISPLAY'' begins with a colon
("'':''") or with "''unix:''", then VirtualGL will assume that the X server
connection is local and will enable the X11 Transport as the default.  In
some cases, however, the ''DISPLAY'' environment variable within the X proxy
may not begin with a colon or "''unix:''".  In these cases, it is necessary to
manually enable the X11 Transport by setting the ''VGL_COMPRESS''
environment variable to ''proxy'' or by passing an argument of ''-c proxy'' to
''vglrun''.

** Using VirtualGL with an X Proxy on a Different Machine
{anchor: X11_Proxy_Usage_Remote}

#IMG: vgltransportservernetwork.png

If the X proxy and VirtualGL are running on different servers, then it is
desirable to use the VGL Transport to send images from the VirtualGL
server to the X proxy.  It is also desirable to disable image compression in
the VGL Transport.  Otherwise, the images would have to be compressed by
the VirtualGL server, decompressed by the VirtualGL Client, then recompressed
by the X proxy, which is a waste of CPU resources.  However, sending images
uncompressed over a network requires a fast network (generally, Gigabit
Ethernet or faster), so there needs to be a fast link between the VirtualGL
server and the X proxy server for this procedure to perform well.

The procedure for using the VGL Transport to display 3D applications from a
VirtualGL server to a remote X proxy is the same as the
[[#X11_Forwarding][procedure]] for using the VGL Transport to display
3D applications from a VirtualGL server to a remote 2D X server, with the
following exceptions:

	#. The "client" in this case is really the X proxy server.

	#. The "X server" is really the X proxy.

	#. Once connected to the VirtualGL server with SSH, it is recommended that
		you disable image compression in the VGL Transport by either setting
		the ''VGL_COMPRESS'' environment variable to ''rgb'' or passing an argument
		of ''-c rgb'' to ''vglrun'' when launching VirtualGL.  Otherwise, VirtualGL
		will detect that the connection to the X server is remote, and it will
		automatically try to enable JPEG compression.
