These will always be byte streams at heart, so let's try to keep them
with a proper type. Should make it clearer how they will be used.

Major restructuring of how streams work. Neither input nor output
streams are now blocking. This avoids stalling the rest of the client or
server when a peer is slow or unresponsive.

Note that this puts an extra burden on users of streams to make sure
they are allowed to do their work once the underlying transports are
ready (e.g. monitoring fds).

We need to track different things in the server and client, so
separate things to two independent structures to keep things more
clear.

Clang doesn't like when struct and class are used to refer
to the same thing interchangeably.

Fixes all instances of:

In file included from /home/shade/dev/tigervnc/common/rfb/CConnection.cxx:29:
In file included from /home/shade/dev/tigervnc/common/rfb/CConnection.h:28:
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:35:3: error: class 'Exception' was previously declared as a struct [-Werror,-Wmismatched-tags]
  class Exception;
  ^
/home/shade/dev/tigervnc/common/rdr/Exception.h:32:10: note: previous use is here
  struct Exception {
         ^
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:35:3: note: did you mean struct here?
  class Exception;
  ^~~~~
  struct
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:43:3: error: class 'Rect' was previously declared as a struct [-Werror,-Wmismatched-tags]
  class Rect;
  ^
/home/shade/dev/tigervnc/common/rfb/Rect.h:68:10: note: previous use is here
  struct Rect {
         ^
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:43:3: note: did you mean struct here?
  class Rect;
  ^~~~~
  struct

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 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.

This avoid a lot of unnecessary middle men. This also pushes the
responsibility for pixel format conversion into the encoders and
decoders. The new bufferFromBuffer() is used for direct conversion,
rather than PixelTransformer/TransImageGetter.

The connection object is a much more appropriate object for the
decoders and encoders to keep track of. Besides the streams, it also
contains state like connection parameters.

We have no use for it, so let's keep things simple.

encoding in the RFB protocol has always been signed, and signed values
are also used in the specification (ie DesktopName = -307 etc). In the
code, however, unsigned types were used in a number of places, but not
all, which causes warnings. This patch fixes the problem by switching
to signed values everywhere.



git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3968 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@589 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/branches/merge-with-vnc-4.1.1@522 3789f03b-4d11-0410-bbf8-ca57d06f2519

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2 3789f03b-4d11-0410-bbf8-ca57d06f2519