Siarhei Siamashka <siarhei.siamas...@gmail.com> writes: > As a workaround (instead of plugging such holes all over the place), > we might allocate the temporary buffers for general path, initialize > them once and keep the pointers to these buffers in TLS. However this > is not very nice and may hide real problems.
If we did this, it might make sense to allocate a large array, and then hand out chunks of that array dynamically. Such a memory allocator could be pretty simple if all allocated memory was considered freed at the end of each composite operation. E.g., at the beginning of pixman_image_composite() a 'current' pointer, also stored in TLS, would be initialized to the array, and then some utility function would just hand out new chunks as needed. - Iterators could be dynamically allocated which would mean the structs didn't have to be public, so individual implementations could put whatever fields they wanted into the structs instead of relying on these fields: /* These fields are scratch data that implementations can use */ void * data; uint8_t * bits; int stride; - The temporary scanlines for the separable scalers could be allocated this way. I'm not sure this is worth the complexity though. > By the way, going through the general path is not very good for > performance. It would be really interesting to see why it does not > hit some sse2 optimized fast path in this particular case. Using a gradient source will cause this fallback. Of course writing SSE/SSE2 (or AVX/AVX2 for people with Haswell hardware) iterators for radial or linear gradients would be an excellent way for someone to spend their Christmas vacation. Søren _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman