[cairo] [PATCH 1/2] gl: Add a first bit of general documentation on cairo-gl usage.

M Joonas Pihlaja jpihlaja at cc.helsinki.fi
Fri Feb 4 07:28:12 PST 2011


On Thu, 3 Feb 2011, Benjamin Otte wrote:

> Well, the other option is to rethink cairo's threading guarantees and
> say "cairo requires that every device is used in the same thread only"
> or "threading guarantees depend on the backend".

Users can't understand what a device actually is because no backend
has really documented their own device (current patch exempted), and
how it interacts with threading, the underlying resources being
managed, or even what those resources are.

Moreover, the device API has additional troublesome issues wrt.
multithreading at its very core:  You're supposed to flush the device
and then acquire it, but that's a race condition right there between
the flush and the acquire.  You also can't flush after you've acquired
it because flushing can recursively acquire other devices, which could
lead to a possible deadlock.  Thus it's up to the user to serialise
their "flush & acquire" operation using yet another layer of locking.
Surely nobody wants to require that.

> Which does not look like a problem as it seems that - nobody
> bothered fixing the image backend to make it threadsafe yet

It's only thread unsafe for normal non-text drawing in 1.10.  A lot of
people are still happily using 1.8 where the pixman_image_ref() issue
doesn't occur (1.8 doesn't cache pixman images.)

Joonas


More information about the cairo mailing list