[Pixman] [PATCH 0/3] Composite args in stack allocated struct

[Soeren Sandmann]

Søren Sandmann <sandmann at cs.au.dk> writes:

>>> I'm actually all for this change if it gets confirmed to work a bit
>>> better and faster (and I expect that it should, considering that all
>>> this data can be passed through some nested calls multiple
>>> times). Hopefully we are not running in circles.
>>
>> The FbComposeData struct was used in precisely one place to pass
>> information between two functions. It could not possibly have provided
>> any benefit as it existed in X server 1.3, which is the version that
>> eventually became pixman.
>>
>> I think what might have happened is that full support for FbComposeData
>> was introduced in one of the several forks that existed around 2005 and
>> never merged into Xorg, except for that one place. 
>>
>> So I'm not too worried about running in circles, but I don't know if it
>> is actually a performance advantage. I tend to think that if such
>> microoptimizations really result in measurable performance advantage,
>> then then the problem should probably be fixed in some other way.
>
> The following emails contain a rebased version of this branch against
> master.

Performance numbers:

Before:
[ # ]  backend                         test   min(s) median(s) stddev. count
[ # ]    image: pixman 0.23.1
[  0]    image   firefox-talos-gfx-20090702   36.974   36.987   0.03%  4/6

After:
[ # ]  backend                         test   min(s) median(s) stddev. count
[ # ]    image: pixman 0.23.1
[  0]    image   firefox-talos-gfx-20090702   37.036   37.072   0.04%  5/6

So it's about 0.2% slower on this benchmark, which is very glyph heavy
and therefore calls pixman_image_composite32() a lot. But the main point
to me is performance, but the ability to pass more information to the
compositing routines. It's also a reduction in line count.


Soren