We need to make sure the display server has finished reading our
previous update before we overwrite the buffer with the next update.

This is based on comparing CPU time with elapsed time, which means
that the tests can be heavily influenced by other load on the test
machine.

The damage tracking region needs to be protected from multiple
threads accessing it at once. The rest should be fine though.

We can start creating more decoding threads now that we handle
rect ordering properly. No point in creating more threads than
there are CPUs though.

The cost is some more load on malloc(), but it should be small
compared to the gains of spreading the CPU heavy JPEG decoding
over multiple CPUs.

Some encodings only cause dependencies between rects some of the
time. Make sure we can allow parallel decoding of those rect that
aren't dependent on each other.

Some encodings must be handled in the order they are received.
Make sure we respect this in the decode manager.

Allows us to add attributes later that affect of the decoder
manager deals with the decoders.

This implements the basic infrastructure for multi-threaded
decoding of rects. However there is just one thread reading data
and one thread decoding it. More logic is needed to safely decode
multiple rects at the same time.

We need more callbacks for correct operation of multi-threaded
rect decoding.

We need the newer versions of Windows to get access to better
thread primitives.

It previously only did a reset of the ZlibInStream object, not the
underlying zlib stream. It also had the side effect of flushing
the underlying stream and disassociating from it.

Clear things up by changing the naming, and introducing a proper
reset function (which is needed by the Tight decoder).

We need to split these steps up in preparation for multi-core
support. Reading needs to be done in a serial manner, whilst
decoding can be done in parallel.

This also involved a rather large cleanup of the Tight decoder.

Done in preparation for multi-core decoding. Keeps the complexity
out of the other classes. This also moves ownership of the
framebuffer in to CConnection. It's the CConnection object that is
aware of the threads and how to synchronise with them. Therefore
the ownership of the framebuffer must also be there to make sure
it isn't deleted whilst threads are working.

Time spent executing in the kernel is as much of a performance problem
as time spent in userspace. Make sure both numbers are included.

mingw has a perfectly functional gettimeofday() so use that instead
of having multiple copies of our own version.

Xvnc does not understand -i as an alias to -interface anymore (since commit f8e3b34c69)
but it is still listed in the man page.

Fix man accordingly

Signed-off-by: Kir Kolyshkin <kir@openvz.org>

libjpeg doesn't update the buffer state before calling the
empty_output_buffer() callback so we need to flush everything,
not just the apparent size.

On some systems, the build was picking up jpeglib.h from the system
include directories, and if the system's version of libjpeg[-turbo] used
a different API/ABI version than the one specified in JPEG_LIBRARY, this
led to a "Wrong JPEG library version" error at run time.

Meta no longer sends Super.

Since 83e019f599.

Improved x509 auth for java viewer

Some exceptions were causing all viewers to exit, not just the
one that threw the exception.