* 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-OpenGL elements of the 3D application's GUI.  The VGL Transport also
requires an X server to be running on the client, which makes it generally more
difficult to deploy and use 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 3D 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 frames to the X proxy at a very fast rate,
the proxy must be able to compress the frames 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 [[http://turbovnc.org][TurboVNC]], a high-speed VNC
(Virtual Network Computing) variant that is designed specifically to achieve
high levels of performance with VirtualGL.  More information about TurboVNC,
including instructions for using it with VirtualGL, can be found in the
TurboVNC User's Guide.

Many other X proxy solutions work well with VirtualGL, and some of these
solutions provide compelling features (seamless windows, for instance), but
none of these X proxies matches the performance of TurboVNC, as of this
writing.

** 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 rendered frames to the
X proxy through shared memory rather than over a network.

#IMG: x11transport.png

With this configuration, you can usually invoke

#Pverb: <<---
/opt/VirtualGL/bin/vglrun __[vglrun options]__ __3D-application-executable-or-script__ __[arguments]__
---

from a terminal inside of the 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 2D X
server is on the same machine and will enable the X11 Transport as the default.
In some cases, however, the ''DISPLAY'' environment variable in the X proxy
session 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 rendered frames from the VirtualGL
server to the X proxy.  It is also desirable to disable image compression in
the VGL Transport.  Otherwise, the frames 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 an X proxy on a different machine is the same as the
[[#X11_Forwarding][procedure]] for using the VGL Transport to display
3D applications from a VirtualGL server to a client-side 2D X server, with the
following exceptions:

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

	#. The "2D X server" is the X proxy.

	#. 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 2D X server is on a different
		machine, and it will automatically try to enable JPEG compression.
