[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