[cairo] cairo_matrix_t

[Carl Worth]

On Tue, 7 Sep 2004 09:25:31 -0700, Bill Spitzak wrote:
> The only good reason for the current implementation is for thread safety. But  
> really, if another thread is going to change the matrix in your cairo 
> context, you still can't guarantee that the one you copied is in fact the 
> current one, so I don't see what this possibly buys you.

There's a bit more to it than that though. The current cairo
implementation makes it very easy to write a thread-safe program, but it
doesn't mean that multiple threads can call into the same cairo_t object
willy-nilly. See below.

>                                                          In fact I would 
> prefer if cairo contexts (or any other objects, such as surfaces or windows) 
> had no guarantee of thread safety except that using seperate objects is 
> thread-safe. Multiple threaded programs must either use different objects per
> thread, or do their own locking. I would think this would be a much more 
> efficient implementation.

What you prefer is actually what we have right now. In order to get a
thread-safe program you have to use independent cairo_t objects in each
thread or else do your own locking.

The benefit of the current implementation is that locking is only needed
on a per-object basis, (ie. two threads calling in through the same
cairo_t* or the same cairo_matrix_t*, etc.). But, if we were to make
cairo_current_matrix return a non-copied pointer to the CTM inside the
cairo_t, then we've changed that model. Then, locking would be necessary
between one thread with that cairo_matrix_t* and another with the
original cairo_t*.

This is still possible for the user to get right, but it is harder, and
the auditing rules are much more complex.

So at the very least there's a trade-off of conveniences here, if not a
trade-off of correctness for convenience.

-Carl