[cairo] RFC: duplicating, storing and serializing drawing operations

Nicolas George nicolas.george at ens.fr
Tue Dec 26 11:06:49 PST 2006

Le sextidi 6 nivôse, an CCXV, Kalle Vahlman a écrit :
>			    How that happens is another thing, and if I
> get you right, you'd like it to be recreated by a library between the
> application and cairo (or an API in cairo itself) that has recorded
> the drawing commands the application has used?

Yes, that is exactly it.

> That sounds very useful indeed.

I am glad you agree.

> Yes, the example code was very enlightening on the intent of all this
> :) but it still didn't invalidate everything I said.

That is true, we were just not talking about the same part of the program.

> Ah, I didn't realize you were thinking about separate processes
> (should read more carefully) instead of a threaded library that takes
> care of the locking etc.

In fact, I evoked both solutions. The point is that to add an event handler
in a program that has no room for it, parallel execution is necessary. In
can be achieved in either ways: a lightweight thread or a heavyweight
process. Either solution has it advantages and drawbacks.

A separate process requires serializing-unserializing, but when it is done,
it is the simplest solution, and it also makes possible for the window to
outlive the program.

A lightweight thread allow direct access, but requires locking.

For this latter point, locking can either be hidden in the library or
explicitly done by the user. Having to enclose every sequence of drawing
operations inside graphics_lock() / graphics_unlock() would be an acceptable
overhead for me, but I would rather avoid it.

Mostly, I would rather use a separate process.

>			   I was simply pointing out that making cairo
> do the locking would be more beneficial than that.

Cairo itself does little locking. Look at _cairo_gstate_stroke for example:
there is room for a race condition between _cairo_surface_set_clip and
_cairo_surface_stroke; obviously, stroking to the same surface from
different threads is not supported.


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061226/c4ca5cf4/attachment.pgp

More information about the cairo mailing list