This is the only unused var change I'll want to revisit eventually,
I'm submitting anyway since it doesn't change current behavior. I'm
talking about ignoring the return value from canvas creation. Adding
a print is possible but I didn't test (may be too verbose, also
preferable to be a debug print if so, and we don't have that option
in the code atm - probably an environment variable will do, or adding
some spice_server_set_logging_level api, maybe even
spice_server_set_logging_fd?)

Allow top_down flag to have any value, only ASSERT it is positive
when needs to be positive and zero otherwise. Allows older server
bug of sending 4 instead of 1 in top down flag to not affect newer
clients (previous patch fixes server).

Seems the OSX gcc warns on saveRight not being initialzied.

Resetting the transform is done by setting it to the identity
transform, not passing in NULL. Passing in NULL causes a crash.

When scaling part of an image we need to specify the source
coordinates in transformed coordinates. For large magnifications this
means we will get pretty large values.

Now, if e.g. src_x * transform is larger than 32765, then the
coordinate ends up outside the pixman 16bit image size, so the
rendering will not work.

The fix is to make the src_x/y offset part of the transformation.
This means its automatically transformed by the correct scaling, and
the coordinates passed into pixman are not (typically) over 16bit.

This reverts commit e13be77f33609cb3fdae354ce1f2686ae865f9e0.

When scaling part of an image we need to specify the source coordinates
in transformed coordinates. For large magnifications this means
we will get pretty large values.

Now, if e.g. src_x * transform is larger than 32765, then the coordinate
ends up outside the pixman 16bit image size, so the rendering
will not work.

In order to work around this we generate a "sub-image" of the pixman
image such that the src_x/y values we have to specify are zero (or near
zero).

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.