Søren Sandmann <[email protected]> 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 _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
