Siarhei Siamashka <siarhei.siamas...@gmail.com> writes: > An interesting question is whether atomic refcounting is the only fix > required > or it is just the tip of the iceberg? > > How the multithreaded rendering is supposed to be done with cairo/pixman? I > can > imagine several scenarios: > a) Some set of images or icons is used from multiple threads, it would be > just a waste of RAM to require each thread to have its own copy of all the > same stuff > b) The destination image is split into a number of slices so that they can be > rendered by different CPU cores in order to improve performance > c) One thread is doing rendering (repeatedly drawing some image for example), > and another thread is poking it periodically at any arbitrary moments to > change > transformation matrix, filter, repeat type or anything else. > > For the cases (a) and (b), I would say it really makes a lot of sense sharing > at least pixel buffers, and maybe some immutable image information (like > image > format, width, height, stride, ...). But I'm not so sure about the > pixman_image_t structure itself. > > And the case (c) is in my opinion a real recipe for a performance disaster, > due > to having the need to infest a significant part of code with atomic operations > and thread synchronization primitives (gstreamer works this way).
There are really two separate things to consider: The first is which thread-related guarantees will pixman give? Adding atomic refcounts would add a new guarantee that multiple threads can do ref/unref simultaneously without causing double frees. I do think we should probably go at least one step further and allow the same image to be used in a read-only way from multiple threads. "Read-only" here obviously means not using the image as a destination, but also not changing any of the properties such as transformations or filters. The only real reason, aside from the refcounting, that the read-only access doesn't work at the moment is that the images contains some cached information: the flags field and the extended format. Potentially, strange things could happen if two different threads try to update those fields at the same time, although I don't think it's a real problem with the memory models on common architectures (since presumably the two threads would come to the same result and the "dirty=FALSE" write would not be visible before earlier updates). Still, it would be good to get this on a less shaky foundation. 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. Soren _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman