[cairo] Operator optimization based on source or dest opacity

[Antoine Azar]

I've reworked my patches according to the comments from Soeren.

Here are 3 patches attaches to this message
Patch1: Move all composition operators to their own c/h files
Patch2: Optimize operators depending on source/dest opacity
Patch3: Optimize a bit the checks to select a fast code path

The main changes from my previous patches:
Patch1:
-moved all inline operators to the c file

Patch2:
-pixman_image_is_opaque() now checks for alpha-maps.
-moved all the checks of repeat_none and transforms inside 
pixman_transformed_image_is_opaque().
-Split that function in 2 and created pixman_image_is_opaque to check 
for the opacity of an untransformed image (useful for checking the 
dest, which doesn't really care about its repeat mode and such)
-Moved all of the operator switching code inside its own function 
pixman_optimize_operator()
-Fixed some minor coding style issues

Patch3:
-Just separated it from patch2 (was included inside before)


Best,
Antoine




At 05:20 PM 2/27/2008, Soeren Sandmann wrote:
>Antoine Azar <cairo at antoineazar.com> writes:
>
> > >- pixman_image_is_opaque() needs to handle alpha-maps.
> >
> > I'm not sure I understand what you mean. How do you check if an alpha
> > map is opaque without checking every pixel of it?
>
>An alpha map is something you can set on an image using
>pixman_image_set_alpha_map(). It is a way of using an external alpha
>channel for the image.
>
>Nobody uses them, but they are exposed through RENDER in the X server,
>so we shouldn't break them. It's totally fine to just say
>
>         if (image->common.alpha_map)
>                 return FALSE;
>
>or something.
>
> > >- In general, it looks to me like the code in pixman-pict.c that
> > >checks whether the optimization is applicable, is really checking
> > >whether the image is opaque. If so, it should be moved into
> > >pixman_image_is_opaque().
> >
> > Yes and no. I originally didn't include the other checks in the
> > function because I wanted to keep it generic enough for other uses.
> > It basically just checks if a source contains alpha information or
> > not which I guess could be useful at other places. The other checks
> > take into account *how* the source is being used and if this
> > introduces any transparency. So I can see a valid point either way,
> > let me know if you would still rather have the checks included in
> > pixman_image_is_opaque.
>
>I see the transformations and filters as integral to the images, not
>as instructions on how to composite them. So a pixman image with a
>transformation set is not "a normal image that will be used in a
>transformed way", but rather "a set of pixels that happen to be the
>result of a transformation applied to a different set of pixels".
>
>Similary, when repeat is set, the image really is an infinite set of
>pixels, not a finite set that happens to be repeated over and over.
>
>Less philosophically, I don't see any way the information that an
>image is opaque could ever be useful without also checking that the
>transformation and filter don't reintroduce translucency.
>
>
>Soren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-Simplified-a-bit-the-checks-to-getting-a-fast-code-p.patch
Type: application/octet-stream
Size: 1175 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080228/12f23bc2/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-Moved-all-composition-operators-from-pixman-compose.patch
Type: application/octet-stream
Size: 73818 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080228/12f23bc2/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-Implemented-operator-optimization-espescially-used.patch
Type: application/octet-stream
Size: 10562 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080228/12f23bc2/attachment-0005.obj