The OpenGL renderer isn't really useful right now, its not quite up
to date, its not really faster than software and it only supports a limited
subset of drivers. So, lets disable it for now.
Long term opengl rendering of the 2d part of spice is important if we want
to combine 2d and 3d rendering (say if spice adds opengl support in the
protocol). But until then this is isn't useful for normal use.
Right now we always assume pointers are stored as SPICE_ADDRESS,
i.e. 64bit, independent on the size sent on the network.
This is required for 64bit architectures of course, but slightly overkill
on 32bit architectures, so needs fixing when all SPICE_ADDRESS elements
can be made internal.
We move all message structs from spice-protocol to spice as
we want to be able to change these as needed internally. The
on-network format is no longer defined by these structures anyway,
but rather by the spice protocol description.
When a message has been read from the network we now pass it into
the generated demarshaller for the channel. The demarshaller converts
the network data to in-memory structures that is passed on to the
spice internals.
Additionally it also:
* Converts endianness
* Validates sizes of message and any pointers in it
* Localizes offsets (converts them to pointers)
* Checks for zero offsets in messages where they are not supported
Some of this was previously done using custom code in the client, this
is now removed.
The "spice.proto" file describes in detail the networking prototcol
that spice uses and spice_codegen.py can parse this and generate
demarshallers for such network messages.
When a surface is sent to the client using red_send_surface_image, operations were already
performed on it. Thus it may combine, especially if it is a primary surface, both "picture-like" areas
and areas that are more "artificial". In order to avoid noticeable artifacts, such surface will be sent lossless.
The code also handles cases in which the server doesn't hold anymore these surfaces parts, i.e., when
it holds a more updated version of them. This scenario is handled by replacing commands that were rendered, with images.
1) add an option to determine if a bitmap can be sent lossy to the client
2) when required, replacing lossy cache items with their correspending
lossless bitmaps
