Bug 9148

Summary:	invalid rendering when painting large scaled-down surfaces
Product:	cairo	Reporter:	Ed Swartz <eswartz>
Component:	image backend	Assignee:	Carl Worth <cworth>
Status:	RESOLVED FIXED	QA Contact:	cairo-bugs mailing list <cairo-bugs>
Severity:	major
Priority:	high
Version:	1.2.4
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Test case showing error Cheat and avoid range overflow in the pixman_matrix_t for this particular case

Description Ed Swartz 2006-11-24 13:44:18 UTC

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.

Comment 1 Ed Swartz 2006-11-24 13:45:20 UTC

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

Comment 2 Chris Wilson 2008-09-29 08:37:32 UTC

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.

Comment 3 Chris Wilson 2008-10-30 11:09:32 UTC

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.