* Compatibility Guide
{anchor: Compatibility}

In order to realize the full performance benefits of TurboVNC, it is necessary
to use a TurboVNC server and a TurboVNC viewer in concert.  However, TurboVNC
is fully compatible with [[http://www.tigervnc.com][TigerVNC]], TightVNC,
RealVNC, and other VNC flavors.  You can use the TurboVNC Viewer to connect to
a non-TurboVNC server (or vice versa), although this will generally result in
some decrease in performance.

The following sections list additional things to bear in mind when mixing
TurboVNC with other VNC flavors.

** TightVNC or TigerVNC Servers

	* TightVNC and TigerVNC specify the JPEG quality level on a scale from 0 to 9.
		This translates to actual JPEG quality as follows:

		TightVNC JPEG Quality Levels :: {:}
		|| JPEG quality level    || 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 || 9 ||
		| Actual JPEG quality    |  5 | 10 | 15 | 25 | 37 | 50 | 60 | 70 | 75 | 80 |
		| Actual YUV subsampling | 2X | 2X | 2X | 2X | 2X | 2X | 2X | 2X | 2X | 2X |
		#OPT: hiCol=first

		{anchor: TigerVNC_JPEG_Qual}
		TigerVNC JPEG Quality Levels :: {:}
		|| JPEG quality level         ||  0 || 1 || 2 || 3 || 4 || 5 || 6 || 7 || 8 ||  9 ||
		| Actual JPEG quality         |  15 | 29 | 41 | 42 | 62 | 77 | 79 | 86 | 92 | 100 |
		| Actual YUV subsampling      |  4X | 4X | 4X | 2X | 2X | 2X | 1X | 1X | 1X |  1X |
		| Average compression ratio * | 100 | 80 | 70 | 60 | 50 | 40 | 30 | 25 | 20 |  10 |
		#OPT: hiCol=first

		!!! * Experimentally determined by compressing every 10th frame in the
		SPECviewperf 9 benchmark suite

	TurboVNC, on the other hand, includes extensions to the Tight protocol that
	allow the JPEG quality to be specified on the standard 1-100 scale and
	allow the JPEG chrominance subsampling to be specified seperately.
	TigerVNC 1.2 and later includes the same extensions on the server side, so
	the TigerVNC 1.2 Server will behave like the TurboVNC Server when a
	TurboVNC Viewer is connected to it.
	{nl}{nl}
	When a TurboVNC viewer is connected to a TightVNC or TigerVNC 1.0/1.1 server,
	setting the JPEG quality to N in the TurboVNC Viewer sets the JPEG quality
	level to N/10 in the TightVNC or TigerVNC server.  For instance, if you set
	the JPEG quality to 95 in the TurboVNC Viewer, this would translate to a JPEG
	quality level of 9, which would set the actual JPEG quality/subsampling to
	80/2X if connected to a TightVNC server or 100/1X if connected to a TigerVNC
	1.0/1.1 server.
	{nl}{nl}

	* Changing the JPEG chrominance subsampling option in the TurboVNC Viewer has
		no effect when connecting to a TightVNC or TigerVNC 1.0/1.1 server.
		{nl}{nl}

	* Although compression levels 2-9 cannot be set using the TurboVNC Viewer
		GUI, you can still specify these higher compression levels from the
		TurboVNC Viewer command line.  It should be noted, however, that
		our experiments have shown that compression levels higher than 5 are
		generally not useful in the TightVNC or TigerVNC Servers.  They increase
		CPU usage exponentially without providing any significant savings in
		bandwidth relative to Compression Level 5.
		{nl}{nl}

	* TurboVNC supports an extension to the TightVNC protocol that allows the
		server to tell the viewer not to use Zlib to decompress a particular
		rectangle.  Zlib introduces a tremendous amount of performance overhead,
		even when compression level 0 (no compression) is used.  Thus, when a
		TurboVNC viewer requests Zlib compression level 0 from the TurboVNC Server,
		the TurboVNC Server bypasses Zlib altogether.  TightVNC and TigerVNC
		servers do not support this extension, and thus they will still use Zlib to
		"compress" data even if you request no Zlib compression using the TurboVNC
		Viewer.
		{nl}{nl}

	* The TightVNC Server will use much more CPU time across the board than the
		TurboVNC Server, all else being equal.  TigerVNC 1.2 can be made to perform
		similarly to TurboVNC, barring the absense of multithreading in the former,
		but this requires using non-default settings in TigerVNC.  The default
		TigerVNC settings are roughly equivalent to Compression Level 2 in
		TurboVNC, which will use significantly more CPU time than Compression
		Level 1.  Additionally, TigerVNC does inter-frame comparison by default
		whenever Compression Level 2 or above is selected, and this increases CPU
		time even more.  Compression Level 1 should be used in TigerVNC in order to
		simulate the behavior of TurboVNC's "Tight + JPEG" encoding methods.

** TightVNC or TigerVNC Viewers

	* The TurboVNC Server will attempt to emulate the behavior of a TigerVNC
		server and will translate JPEG quality levels into actual JPEG quality and
		subsampling as specified in {ref prefix="Section ": TigerVNC_JPEG_Qual}.
		{nl}{nl}

	* When either a TightVNC or TigerVNC viewer is connected to a TurboVNC
		server, setting the compression level to 0 in the viewer will, in certain
		cases, cause the connection to abort with a "bad subencoding value" error.
		This is because the TurboVNC Server is attempting to send the image tiles
		with no Zlib compression, and the TightVNC and TigerVNC viewers don't
		support this.
		{nl}{nl}

	* The TurboVNC Server only supports compression levels 1-2 if JPEG encoding
		is enabled, and compression levels 0-1 if JPEG encoding is disabled.
		Extensive experimentation has shown that TurboVNC's encoding methods cannot
		produce significantly tighter output by increasing the Zlib compression
		level beyond this, except on rare corner cases (such as the console output
		of a large compilation) that are not performance-critical to begin with.
		In general, increasing the Compression Level from 1 to 2 with JPEG enabled
		will increase the CPU usage for most 3D and video workloads without
		providing any significant bandwidth savings.  However, Compression Level 2
		can be shown to reduce bandwidth by 20-40% (with a commensurate increase in
		CPU usage) for certain types of workloads that have low numbers of unique
		colors.
		{nl}{nl}

** RealVNC

The TurboVNC Viewer supports the Hextile and Raw encoding types, which are
compatible with RealVNC.  Neither of these encoding types can be selected from
the TurboVNC Viewer GUI, but Hextile will be selected automatically when
connecting to a RealVNC server.  Raw will be automatically selected when
connecting to a VNC server running on the same machine as the viewer.  Both Raw
and Hextile can also be manually selected from the ''vncviewer'' command line.
The TurboVNC Server additionally supports the CoRRE, RRE, Zlib, and ZRLE
encoding types, for compatibility with RealVNC viewers.

The Raw encoding type can perform well on gigabit links, if you can spare the
bandwidth.  Hextile, however, uses very small tiles, which causes it to incur
a large amount of computational overhead.  It compresses too poorly to perform
well on slow links but uses too much CPU time to perform well on fast links.
Thus, neither Raw nor Hextile should be used unless absolutely necessary.  One
interesting note, however, is that many of the TurboVNC viewer enhancements
(including optimized blitting, hiding network latency, and double buffering)
are available even when using these legacy encoding types.
