[cairo] Operator optimization based on source or dest opacity

Soeren Sandmann sandmann at daimi.au.dk
Wed Feb 27 09:36:02 PST 2008


Antoine Azar <cairo at antoineazar.com> writes:

> I've taken the advice of various people on the list, and ported this
> optimization from Cairo to Pixman. I've basically checked if / how
> each operator could be optimized if the source and / or dest was
> opaque, and use the optimized operator if possible. The most obvious
> case of this being OVER -> SOURCE for an opaque source. This speeds up
> enormously some common cases, such as a 6.7X improvement in painting a
> RGB source over a 256x256 RGBA dest.
> 
> The optimized operators are:
> PIXMAN_OP_OVER, PIXMAN_OP_OVER_REVERSE, PIXMAN_OP_IN,
> PIXMAN_OP_IN_REVERSE, PIXMAN_OP_OUT, PIXMAN_OP_OUT_REVERSE,
> PIXMAN_OP_ATOP, PIXMAN_OP_ATOP_REVERSE, PIXMAN_OP_XOR,
> PIXMAN_OP_SATURATE

I like the general idea, but I think this patch needs more work. Some
comments:

- pixman_image_is_opaque() needs to handle alpha-maps.

- 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().

- The remaining code in pixman-pict.c that deals with the optimization
  should be moved to its own function, like this:

        op = optimize_operator (op, src, mask, dst);

  The pixman_optimize_operator() from your patch can then be
  integrated into this.

- Coding style:

+    case BITS:
+        {
+            if(PIXMAN_FORMAT_A(image->bits.format))
+                isSourceOpaque = FALSE;
+            break;
+        }

   I'm not very draconian about coding style, but please eliminate
   those braces. Also, when such braces are necessary, please align
   them with the 'case' keyword.

- I'd like to see the unrelated changes to the fast path search
  dropped. We can look at them later if they do make a performance
  difference.

> I've benchmarked the most relevant performance cases and posted them here:
> http://www.antoineazar.com/optimization_final.htm
> Any perf increase above 5% is in bold green and perf decreases below
> 5% in bold red

Those numbers look ok to me. Without applying the patch from the end
of this message:

    http://lists.freedesktop.org/archives/cairo/2007-June/010813.html

the cairo performance test numbers will be somewhat unreliable.

> I'm also attaching another patch (to be applied first) that cleans up
> further pixman-compose.c by moving all the composition operators to
> their own files, pixman-compose-operators.c/h

I like this; in fact, I'd like to see even the inlined functions moved
into the C file instead of the header file.

There are some changes coming soon that will replace these files with
auto-generated ones to deal with 16 bit compositing. This separation
will become useful at that point.


Soren


More information about the cairo mailing list