I have a program that renders source surfaces of varying sizes onto a target surface. This is using the image backend only. (More precisely, I've only tested this backend.) The source surfaces have various sizes, but are scaled down to have the same effective size on the target (i.e. kind of like mipmapping). When the source image is larger than the surface, and the CTM is scaling the image down to a small size, and the CTM translates the image toward the bottom right, then the image gets clipped and mangled (when it shouldn't be). Test cases speak louder than words. See the attachment. It's a program that creates PNGs for a series of source image sizes, showing the lower-righthand portion exhibiting error while the upper-lefthand portion remains intact. BTW, the error happens in both 1.2.4 and the git head, but the pixels in the area in interest differ using the git head.
Created attachment 7893 [details] Test case showing error Try it like this: rm -f test_*.png; gcc cairo_scale_bug.c `pkg-config --cflags --libs gtk+-2.0`&& ./a.out && eog test_*.png
Created attachment 19284 [details] [review] Cheat and avoid range overflow in the pixman_matrix_t for this particular case The issue here is range overflow when constructing the pixman_matrix_t for downscaling and placing the image. However for this particular class of transformations we can extend the range of translations supported by using the auxiliary offset vector in the attributes, such that the offset vector contains the integer components of the translation and the matrix contains the fractional values. This seems like a lot of complication to work-around what seems to be an unlikely corner-case.
I've push a cleaned-up patch to master, which will be included with 1.10. Thanks for the bug report!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.