[cairo] semantics of cairo_copy()

[Carl Worth]

Hi Bill,

I just wanted to tie off a few loose ends in this thread, and also
point to upcoming API Shakeup proposals that are relevant to the
topics at hand.

On Tue, 18 Jan 2005 16:48:43 -0800, Bill Spitzak wrote:
> > This is another area I want to clean up in the API. Currently, setting
> > a new target device is a poorly specified operation. Does it reset the
> > current transformation matrix? Does it reset everything in the
> > graphics state?
> 
> Yes, please reset the default matrix and no clip! Do this even if the 
> new target device is the same one as before.

I'll be posting the following shortly:

	API Shakeup: cairo_create and eliminating cairo_set_target_surface

the idea is that with cairo_begin/end_group now in place, there's not
a compelling need to re-target a cairo_t. Instead, association of
cairo_t with a target surface will take place at the time of
cairo_create.

> Yes, please leave the path unchanged by gsave/grestore. This will allow 
> the transformation to be changed, more of the path built, and then 
> restored.

This is the direction we've been considering.

> This will allow many programs to use the Cairo transformation 
> for their drawing,

Yes.

>                    currently they are forced to do their own 
> transformations because they don't want the line thickness to change. (a 
> better idea would be to keep the line thickness in the CTM that was in 
> existence when it was set, but I think your problem with that is that it 
> is incompatable with PostScript and PDF?)

I don't see any problem with line width. In cairo, already, the CTM
used to construct the path can be totally different than the CTM used
for the line width. So the only missing piece is the ability to
change the CTM during path construction and easily restore the
original CTM.

As for "locking" the line width based on the CTM at the time of
set_line_width, I don't think this is consistent. There are many
stroke parameters, (line_width, line_cap, line_join, dash,
miter_limit), and all of these are simply parameters that are set in
the gstate. All of these parameters just sit there until the call to
cairo_stroke at which time they are read and acted upon. So, I think
that that is the most reasonable time to run the line_width through
the CTM.

> The fill+stroke problem can be solved by not actually clearing the path 
> after a fill until the next path-construction operator. Ie you can build 
> a path and fill and stroke it as many times as you want.

That's a good idea. Doing it by default would force a *lot* of new
calls to cairo_new_path. The refinement to this idea that has been
proposed this week is to provide new versions of cairo_fill and
cairo_stroke that do not clear the path. See the upcoming message:

	API Shakeup: cairo_fill_preserve and cairo_stroke_preserve

-Carl
-------------- 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/20050216/f43aeb6b/attachment.pgp