[cairo] Cairo is non-deterministic?

[Carl Worth]

On Tue, 3 Jan 2006 20:30:16 +0100 (CET), Dirk Schönberger wrote:
> 
> > Early versions of cairo (pre 1.0) did have the path as part of the
> > gstate, but we changed this to make it easier to write path-creating
> > functions that can locally modify the CTM within a save/restore block.
> 
> Does this means that the CTM is evaluated only when rendering a
> path?

No. The CTM is examined by all path manipulation functions (move_to,
line_to, etc.).

> This seems to be a change to the Postscript sehmantic (don't know about
> PDF), which should allow things like (sorry for the Pseudocode ;))

There's no change to the PostScript semantics in this regard.

> moveto (0, 1)
> for (int i=0; i<10; i++)
> {
>   rotate(360/10)
>   lineto (0, 1)
> }

That kind of thing will work fine in cairo. And this is a great
example of what I called a "path-creating function" above.

Imagine you wanted to take something like the chunk of code above and
put it into a function called make_regular_polygon which accepted the
number of sides. The caller of make_regular_polygon likely does not
want to see any change to the CTM by calling this function. The most
natural way to do that would be to surround the implementation of the
function body with a save/restore pair.

But if the path were part of the gstate, then this save/restore pair
would also prevent the path modification from being visible to the
caller. So the function would have no effect. In that case, to get the
desired result, the implementation of the path-creating function would
have to avoid calling save/restore and would instead have to manually
save and restore individual elements of the graphics state (CTM,
source pattern, etc.) which would be tedious and error prone.

The fact that the path is _not_ part of the gstate allows
cairo_save/cairo_restore to be used within a path-creating function.

> Agreed, but IMHO this may lead to some confusion to people which may
> expect similar semantics for similar APIs. Cairo has (or had?) a
> sufficiently similar API to things like Postscript, PDF or (Apple)
> Coregraphics, so I think this matters.

Yes, similarity with the "standard" models established by PostScript
and PDF has been an explicit goal in the design of cairo's API. In the
case of "is the path saved as part of the gstate?" it turns out that
PostScript and PDF don't agree, so there's no immediately obvious
"standard" solution.

-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/20060103/c1c71f5c/attachment.pgp