[cairo] API Shakeup: Eliminating cairo_show_surface

[Carl Worth]

On Tue, 03 May 2005 11:57:42 -0700, Bill Spitzak wrote:
> It does sound like that xy should be the only thing that sets the 
> pattern's transform, the current scale should have no effect on it. At 
> least that's my understanding: if I do further cairo_scale calls and 
> draw the pattern won't the pattern be drawn a larger size?

The larger size for the pattern is what I expect (and actually get
right now). The problem I ran into with my test is that the the offset
passed to cairo_set_source_surface is also being scaled, and that's
just wrong since it should be interpreted as a user-space coordinate
at the time of cairo_set_source_offset.

I think that's just an implementation problem and the fix for that is
that the gstate needs to have a notion of a source transform that the
offset can be copied into, (rather than just lodging the offset into
the pattern's transformation matrix as is currently done).

Meanwhile, Owen has a case where he wants to use a pattern that tiles
in device-space coordinates, so he'd like to be able to do something
like:

	cairo_get_matrix (cr, &ctm);

	cairo_identity_matrix (cr);
	cairo_set_source (cr, device_space_pattern);

	cairo_set_matrix (cr, &ctm);

Which could be implemented by "locking" the pattern, (combining the
pattern's transformation into the gstate's source transformation
matrix), at the time of cairo_set_source.

Always doing the lock at the time of cairo_set_source would break the
scaling I expect, so I don't think it's actually what we want in
general.

To summarize my current thought:

1) We need a separate source transformation matrix in the gstate.

2) There's a "lock pattern" operation that combines the pattern's
   matrix and the CTM into the gstate's source transformation.

3) The user wants to be able to control the timing of the lock,
   (often either at the time of set_source or at the time of a drawing
   operation).

So maybe all we need is a new cairo_lock_source(cairo_t *cr) call, so
that the pattern scaling would happen by default and the
device_space_pattern example above would have to have a call to
cairo_lock_source in order to work as desired?

Quite similarly, we could have:

	cairo_pattern_lock (cairo_pattern_t *pattern, cairo_matrix_t *matrix);

which is quite close to PostScript's makepattern operator. This would
be a bit more awkward to use in the example above:

	cairo_get_matrix (cr, &ctm);
	cairo_pattern_lock (cairo_get_source (cr), &ctm); /* [*] */

and I don't know if the extra generality is useful or not.

-Carl

[*] The extra ctm variable is annoying here. The code would be neater
(and less efficient) by treating cairo_matrix_t as a value in the
API. It would also be neater, (and no less efficient), if
cairo_get_matrix just returned a (const) pointer to the current
matrix:

	cairo_pattern_lock (cairo_get_source (cr),
			    cairo_get_matrix (cr));

(I don't know why I can't seem to get the cairo_get_matrix API right.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050503/a8019dc9/attachment.pgp