On Thursday 03 February 2011 01:24:49 Soeren Sandmann wrote: > Siarhei Siamashka <siarhei.siamas...@gmail.com> writes: > > Are we going to have this new code performing linear search in this array > > once per each compositing operation now? It may be bad for performance > > unless some kind of caching (at the time of pixman_image_t creation?) > > can be added later. > > Well for now, there are only three fetchers, so a cache seems like > overkill, but yes, some sort of caching could be added. It could be > done similarly to the fast path cache, where the cache is thread > private and indexed by (format, iter_flags, image_flags) or something > like that. Then it wouldn't have to happen at image creation time and > there would be no issues with locking the images. > > > Also is there a plan to provide SSE2 optimized store functions in > > addition to fetchers later? > > I don't have any plans personally, but if someone wants to write some, > that would certainly be useful. > > > Anyway, with such changes coming, I see more and more reasons to avoid > > general compositing path in pixman as much as possible :) > > I'm not sure I follow? Certainly, if the general path is getting > faster, that would mean there are fewer reasons to avoid it?
I mean that if we are working with a8r8g8b8 image format only, this newly added code is going to cause some extra overhead by walking through the sse2 fetchers array, not finding anything there and only then falling back to general iterator init. This is going to be somewhat slower than it used to work before. I'm quite happy with the other pixman improvements that happened over time. Just the introduction of delegates earlier and now this way of integration for SIMD optimized fetchers seems a bit more heavyweight than needed. -- Best regards, Siarhei Siamashka _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman