On Fri, 7 Jan 2011, Siarhei Siamashka wrote: > I would suggest to generally forbid using the same pixman_image_t from > multiple > threads, but also add a function for creating pixman_image_t clone, which > would share the pixel buffer with the original image and track pixel buffer > lifetime via thread-safe refcounting.
I would totally agree with this model, except that the way cairo is headed is towards read-only sharing of cairo surfaces. This actually worked in practice pre-1.10 for the image surface before pixman started caching derived image attributes and cairo started using pixman_image_ref in its own pixman image cache. Note that in cairo the pixman image caching is related to sharing solid colours to avoid pixman_image_t creation overhead, so it's not just pixel buffers that cairo wants to share across threads. Actually cairo doesn't want to share pixel buffers at the moment at all afaicr, so that requirement is more from the app side. > > The other thing to consider is whether pixman itself should do > > threaded rendering. I think that will eventually be interesting, but > > getting basic thread safety and threading primitives seems to be a > > pre-requisite. > > It might be useful for some operations which are heavy on CPU, such as > gradients or high quality scaling. But for the majority of simple operations > which are memory bandwidth limited, using multiple threads for rendering has > little sense in my opinion. Anything dealing with complex geometry like tessellation or scan conversion can likely benefit from multiple threads, but doing it with low enough overhead so that it's still fast for simple geometry is likely going to be tricky. Cheers, Joonas _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman