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