We will change rfbClientCleanup() to free the data.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Using C++-style comments when building the code with -ansi does not
work, so be more conservative with the comment style.

Replace TightVNC encoder with TurboVNC encoder. This patch is the result of further research and discussion that revealed the following:

-- TightPng encoding and the rfbTightNoZlib extension need not conflict.  Since
   TightPng is a separate encoding type, not supported by TurboVNC-compatible
   viewers, then the rfbTightNoZlib extension can be used solely whenever the
   encoding type is Tight and disabled with the encoding type is TightPng.

-- In the TightVNC encoder, compression levels above 5 are basically useless.
   On the set of 20 low-level datasets that were used to design the TurboVNC
   encoder (these include the eight 2D application captures that were also used
   when designing the TightVNC encoder, as well as 12 3D application captures
   provided by the VirtualGL Project--
   see http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf), moving
   from Compression Level (CL) 5 to CL 9 in the TightVNC encoder did not
   increase the compression ratio of any datasets more than 10%, and the
   compression ratio only increased by more than 5% on four of them.  The
   compression ratio actually decreased a few percent on five of them.  In
   exchange for this paltry increase in compression ratio, the CPU usage, on
   average, went up by a factor of 5.  Thus, for all intents and purposes,
   TightVNC CL 5 provides the "best useful compression" for that encoder.

-- TurboVNC's best compression level (CL 2) compresses 3D and video workloads
   significantly more "tightly" than TightVNC CL 5 (~70% better, in the
   aggregate) but does not quite achieve the same level of compression with 2D
   workloads (~20% worse, in the aggregate.) This decrease in compression ratio
   may or may not be noticeable, since many of the datasets it affects are not
   performance-critical (such as the console output of a compilation, etc.)
   However, for peace of mind, it was still desirable to have a mode that
   compressed with equal "tightness" to TightVNC CL 5, since we proposed to
   replace that encoder entirely.

-- A new mode was discovered in the TurboVNC encoder that produces, in the
   aggregate, similar compression ratios on 2D datasets as TightVNC CL 5.  That
   new mode involves using Zlib level 7 (the same level used by TightVNC CL 5)
   but setting the "palette threshold" to 256, so that indexed color encoding
   is used whenever possible.  This mode reduces bandwidth only marginally
   (typically 10-20%) relative to TurboVNC CL 2 on low-color workloads, in
   exchange for nearly doubling CPU usage, and it does not benefit high-color
   workloads at all (since those are usually encoded with JPEG.)  However, it
   provides a means of reproducing the same "tightness" as the TightVNC
   encoder on 2D workloads without sacrificing any compression for 3D/video
   workloads, and without using any more CPU time than necessary.

-- The TurboVNC encoder still performs as well or better than the TightVNC
   encoder when plain libjpeg is used instead of libjpeg-turbo.

Specific notes follow:

common/turbojpeg.c common/turbojpeg.h:
Added code to emulate the libjpeg-turbo colorspace extensions, so that the
TurboJPEG wrapper can be used with plain libjpeg as well.  This required
updating the TurboJPEG wrapper to the latest code from libjpeg-turbo 1.2.0,
mainly because the TurboJPEG 1.2 API handles pixel formats in a much cleaner
way, which made the conversion code easier to write.  It also eases the
maintenance to have the wrapper synced as much as possible with the upstream
code base (so I can merge any relevant bug fixes that are discovered upstream.)
The libvncserver version of the TurboJPEG wrapper is a "lite" version,
containing only the JPEG compression/decompression code and not the lossless
transform, YUV encoding/decoding, and dynamic buffer allocation features from
TurboJPEG 1.2.

configure.ac:
Removed the --with-turbovnc option.  configure still checks for the presence of
libjpeg-turbo, but only for the purposes of printing a performance warning if
it isn't available.

rfb/rfb.h:
Fix a bug introduced with the initial TurboVNC encoder patch.  We cannot use
tightQualityLevel for the TurboVNC 1-100 quality level, because
tightQualityLevel is also used by ZRLE.  Thus, a new parameter
(turboQualityLevel) was created.

rfb/rfbproto.h:
Remove TurboVNC-specific #ifdefs and language

libvncserver/rfbserver.c:
Remove TurboVNC-specific #ifdefs.  Fix afore-mentioned tightQualityLevel bug.

libvncserver/tight.c:
Replaced the TightVNC encoder with the TurboVNC encoder.  Relative to the
initial TurboVNC encoder patch, this patch also:
-- Adds TightPng support to the TurboVNC encoder
-- Adds the afore-mentioned low-bandwidth mode, which is mapped externally to
   Compression Level 9

test/*:
Included TJUnitTest (a regression test for the TurboJPEG wrapper) as well as
TJBench (a benchmark for same.)  These are useful for ensuring that the wrapper
still functions correctly and performantly if it needs to be modified for
whatever reason.  Both of these programs are derived from libjpeg-turbo 1.2.0.
As with the TurboJPEG wrapper, they do not contain the more advanced features
of TurboJPEG 1.2, such as YUV encoding/decoding and lossless transforms.

* Fixed segfault on shutdown.
* Updated to test all encodings.
* Fixed to operate with encodings that split up rects into
  smaller rects.

This fixes a segfault when a server is invoked with the
'-help' commandline argument.

We have a git repo nowadays and I guess we won't go back to CVS.
Signed-off-by: Christian Beier <dontmind@freeshell.org>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Rather than use noinst_PROGRAMS, check_PROGRAMS will define programs that
are only compiled when someone actually runs `make check`.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The flag handling (both compiler options and include paths) are a mess at
the moment.  There is no point in forcing "-O2 -g" when these are already
the defaults, and if someone changes the defaults, chances are good they
don't want you clobbering their choices.

The -Wall flag should be handled in configure and thrown into CFLAGS once
rather than every Makefile.am.  Plus, this way we can control which
compilers the flag actually gets used with.

Finally, the INCLUDES variable is for -I paths, not AM_CFLAGS.  Nor should
it contain -I. as this is already in the default includes setup.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Thanks to Guillaume Rousse, we now use libtool to build shared libraries.

hide strict ansi stuff if not explicitely turned on; actually use the socklen_t test from configure.ac

really test 20 seconds

passes all encodings except corre (broken) and zrle (not yet implemented
in libvncclient)

libvncclient is not yet reentrant (or threadsafe).

while structure members should not