summaryrefslogtreecommitdiffstats
path: root/common/sw_canvas.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix scaling with large magnificationAlexander Larsson2010-08-311-20/+16
| | | | | | | | | | | | | | 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.
* Revert "Fix scaling with large magnification"Alexander Larsson2010-08-311-104/+32
| | | | This reverts commit e13be77f33609cb3fdae354ce1f2686ae865f9e0.
* Fix scaling with large magnificationAlexander Larsson2010-08-301-32/+104
| | | | | | | | | | | | | | 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).
* canvas: Better coordinate rounding in scalingAlexander Larsson2010-08-271-28/+36
| | | | | | | | | | | | | 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.
* Stride can be negative, so don't use size_t for itAlexander Larsson2010-08-181-1/+1
|
* Properly parse QXLImage to the new-world SpiceImageGerd Hoffmann2010-07-071-18/+0
| | | | | SpiceImage now replaces RedImage and has all image types in it. All image data are now chunked (and as such not copied when demarshalling).
* applying zlib compression over glz on WAN connectionYonit Halperin2010-06-211-0/+6
|
* Client: Use the autogenerated demarshallersAlexander Larsson2010-06-181-10/+0
| | | | | | | | | | | | | | | | 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.
* JPEG support: introducing jpeg encoding for spice bitmapsYonit Halperin2010-06-091-0/+6
|
* Remove all mentions of "cairo" from the codeAlexander Larsson2010-05-031-0/+1332
The command line option is renamed from "cairo" to "sw", and similarly all filenames and types from Cairo to Sw (and similar).
generated by cgit (git 2.34.1) at 2024-05-27 10:34:20 +0000