When scaling in pixman you give the source coordinates in transformed
space rather than in the source coordinates. This is a bit problematic
when both source and destination coordinates are at integer positions, but
the scaling factor is not an exact 16.16 fixed point value. We used
to calculate the transformed source based on the floating point
transformation, which gave the wrong answer sometimes. Now we do the
calculations based on the fixed point transform that we give pixman.
However, even with this patch I can still sometimes see issues related
to this, although they are less bad.
The actual bitmap data was added to the main marshaller rather than
the submarshaller that pointed to the SpiceImage part. This made us
send too short messages failing demarshalling in the client.
When the we reset qxl, we destroy all srufaces. Since surfaces and glz
drawables are no longer dependent, we need to call red_display_clear_glz_drawables explicitly
in order to clear all our drawables references in the server.
Patch adds a "from __future__" import that doesn't affect newer python's but
allows python 2.5.4 to run the code (tested under scratchbox, n900 build environment)
There was an error in how this was encoded in 0.4, which we need
to handle. There is still some issues with the old streams as
the luminocity handling in 0.4 was not correct.
It turns out that using base + sizeof(struct) is not a good way to
access an array at the end of a struct. For SpicePalette sizeof is 16, but
offset of ents is 12. Using this calculation in the demarshaller breaks
things badly, so now we use the actual array member.
Remove all uses of @end in the marshaller, instead just using
the C struct array-at-end-of-struct. To make this work we also remove
all use of @end for switches (making them C unions).
We drop the zero member of the notify message so that we can avoid this
use of @end for a primitive in the marshaller (plus its useless to send
over the wire).
We change the offsets and stuff in the migration messages to real pointers.
