[cairo] rewriting libpixman

[Jeff Muizelaar]

On Wed, Mar 28, 2007 at 09:44:54PM -0700, Daniel Amelang wrote:
> On 3/28/07, Jeff Muizelaar <jeff at infidigm.net> wrote:
> >I have put up a copy of cairo that has a partially rewritten libpixman
> >in the pixman-new branch of my cairo tree.
> >
> >The main change is that all of the hand written special cases have been
> >replaced with machine generated special cases. The impact of this is
> >that now all regular compositing operations will not use the
> >compositeGeneral case. In addition, the python script allows handwritten
> >substitutions to be made. In this case, I've added substitutions using
> >liboil for the operations that it supports. These substitutions cover
> >alot of the common cases and cause a lot of the speed up seen below.
> >I've also included a patch against liboil that adds another useful
> >operation for cairo.
> 
> Nice. So how much bigger does cairo get with all the statically
> generated code compiled in? I remember suggesting this approach once,
> but Soren scared me away. Hmmm...I see 54k lines of C code in
> composite.c.ref. I would have thought it would be worse, actually.

old:
   text    data     bss     dec     hex filename
 459857    4500     236  464593   716d1 src/.libs/libcairo.so

new:
   text    data     bss     dec     hex filename
 887388   17360     268  905016   dcf38 src/.libs/libcairo.so

So, it doesn't look very good. The text size increase isn't that big a
deal because we can emit the kernels in the order of most commonly used
and the unused kernels won't even need to be paged in. However, the more
concerning part is the increase in data (.data.rel.ro) that presumeably
comes from the dispatch table. Anyone have any thoughts on how bad this
is and whether it can be fixed?

> 
> Also, I noticed that when you convert from 16-bit to 32-bit color, you
> don't replicate the upper bits of the 5 (or 6)-bit color component in
> the lower half of the resulting 8-bit color channel. Pixman does that
> currently, and as I understand it, it's the Right Thing To Do to
> prevent fading.

Yeah, the precision conversion code was pretty broken. I haven't
actually done any 565 testing yet, so I didn't need it to actually work.
Anyways, I've fixed it to do the proper multiply by 255 and divide by 31
or 63, but I plan to add support for the bit copying approximation as
well.

> Great stuff! I'll be keeping a close eye on this.

Thanks,

-Jeff