>> 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. pixman/pixman-arm-common.h | 82 +----- pixman/pixman-arm-neon.c | 16 - pixman/pixman-compiler.h | 6 pixman/pixman-fast-path.c | 436 +++++++----------------------------- pixman/pixman-fast-path.h | 38 --- pixman/pixman-general.c | 45 +-- pixman/pixman-implementation.c | 12 - pixman/pixman-mmx.c | 373 +++++++------------------------ pixman/pixman-noop.c | 15 - pixman/pixman-private.h | 51 ++-- pixman/pixman-sse2.c | 486 +++++++++-------------------------------- pixman/pixman.c | 68 +++-- pixman/pixman.h | 6 test/lowlevel-blt-bench.c | 84 ++++--- 14 files changed, 482 insertions(+), 1236 deletions(-) Soren _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
