[cairo] Operator optimization based on source or dest opacity

Antoine Azar cairo at antoineazar.com
Fri Feb 29 22:47:32 PST 2008


Hi Soeren,

>If the convolution has negative coefficients, then the alpha channel
>of the pixel would get something subtracted from it.

A convolution is a weighed average of the pixels under the 
convolution kernel, with the kernel defining the weights. Whether 
they're negative or positive, you'll be averaging 1s together. I 
don't see anyway we could end up with a non-1 alpha value.

>Suppose we have an image with REPEAT_NONE, a NEAREST filter, and this
>affine transformation:
>
>     [ 1  0 -10 ]
>     [ 0  1 -10 ]
>     [ 0  0   1 ]
>
>When we fetch (0, 0, 1), we get the source pixel at (-10, -10, 1),
>which will be 0 since we have REPEAT_NONE. But the if statement in
>your patch will claim that the image is opaque, as far as I can tell.

There might be cairo-independant considerations to take into account 
which I've ignored, but as far as my cairo tests have shown, we're 
sending the correct xSrc and ySrc down to 
PIXMAN_COMPOSITE_RECT_GENERAL so that we always sample inside the 
source and don't waste time sampling inexistant source pixels.

>I am probably missing something here. What is special about 
>pi/2-multiple rotations? I could see pi-multiple rotations around the
>center of the image being special since that would just turn the 
>image upside down and therefore not introduce any new blank pixels.

A rectangular source rotated by pi/2 multiples remains rectangular. 
Again, cairo is sending the correct extents, so if I have a 100x50 
source image translated and then rotated by pi/2, cairo will send a 
width of 50 and a height of 100, and the xSrc and ySrc will be 
adjusted to be at the first pixel of the source. So the only 
transform that can invalidate this optimization is a non pi/2 
multiple rotation.

Did I overlook something?
Thanks,
Antoine 



More information about the cairo mailing list