Since 53f913a we initialize the underlying PixelBuffer with 0x0
dimensions, which means we need to keep more explicit track of what
we are trying to allocate in the setup methods.

Don't allow subclasses to just override dimensions or buffer details
directly and instead force them to go via methods. This allows us
to do sanity checks on the new values and catch bugs and attacks.

We can use a dummy value here as we set up the buffer and stride
further down in the constructor.

Logging revealed that a few empty damage regions are emitted on startup. Those don't need to be rendered to the Surface pixmap.

The Pixmap is filled in as updates from the server arrive. Before the first full update, it would contain undefined contents, which would be rendered onto the ViewPort.
Clearing the Pixmap is only done on startup and when changing the server resolution, so it's not performance critical.

Our XRender code assumes a certain pixel layout which was not
guaranteed on big endian systems. The previous workaround only worked
for some cases, so fix this properly now.

Everyone else seems to get by with using 0600, so let's do the same.

It's not enough that we detach from the shared memory, we must also
tell the X server to do so for it to be freed properly.

This will allow us to render more things than just the framebuffer.

The complex logic waiting for events didn't result in any added
performance, so use the simpler approach.

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

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

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.

It was confusing and not properly used everywhere.
Callers should use the stride they get when they get
the buffer pointer.

This allows us to gracefully fall back to the FLTK code in case the
platform specific code cannot be used.

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