<html> <body> 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 One strange thing I noticed: Adding just one boolean check in pixman.pict.c's  pixman_image_composite function can have wild effects on performance, even though it's not in any critical loop. I can't explain it. Adding a if() check to see if the current operator could be optimized reduced performance by ~20% for tests that didn't switch operators. To counter that effect, I optimized that function too by moving some if statements around. The net result is a perf increase of up to 35%. Anyone able to explain that phenomenon? I've benchmarked the most relevant performance cases and posted them here: <a href="http://www.antoineazar.com/optimization_final.htm" eudora="autourl"> http://www.antoineazar.com/optimization_final.htm</a> Any perf increase above 5% is in bold green and perf decreases below 5% in bold red 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 Best, Antoine </body> </html>