[cairo] cairo_matrix_t

Bill Spitzak spitzak at d2.com
Tue Sep 7 09:25:31 PDT 2004

I have to say I strongly agree with this.

Unnecessary allocation and copying of structures really annoys some 
programmers. You can make all kinds of arguments that it is not that 
inefficient, but even if those arguments were true they would not convince 
them, and that could very well hurt Cairo's chances of becoming popular.

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

It's also trivial to emulate the current implementation atop this, but the 
other way around is 

The rectangle object and anything else that is obviously a fixed-size array 
of double should also be done this way.

On Monday 06 September 2004 08:42 am, Owen Taylor wrote:

> What I did for Pango was almost exactly opposite from this,
> using the PangoMatrix conventions, the above code would
> look like:
>   cairo_pattern_set_matrix (pattern,
>                             cairo_current_matrix (cr));
> and like:
>  cairo_matrix_t matrix = CAIRO_MATRIX_INIT;

Here I would have done cairo_matrix_init(&matrix). This could be a macro if 
you are worried about call overhead, and would allow a faster implementation 
than copying static memory if it is possible.

>  cairo_marix_scale (&matrix, 0.5, 0.5);
>  cairo_pattern_set_matrix (pattern, &matrix);

More information about the cairo mailing list