[Pixman] Making ref counting thread safe

[Siarhei Siamashka]

On Thursday 23 December 2010 23:00:54 Christian Hergert wrote:
> Hi Folks,
> 
> I've been using cairo to do some threaded rendering using an image surface.
> After the rendering completes, it is pushed to an Xlib surface via the Gtk+
> main loop. However, being that pixman_image_ref() and pixman_image_unref()
> use ++ and -- to increment and decrement ref counts, occasionally I get a
> double free in libc. Obviously, this only occurs under the scenario of many
> concurrent renderings.

Hi.

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).

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20110103/0de09a85/attachment.pgp>