[cairo] Cairo is non-deterministic?

[Carl Worth]

On Tue, 3 Jan 2006 22:02:53 +0100, Dirk Schönberger wrote:
> It depends. If I had to do this with a pure Postscript model, I think I
> could circumvent the problem by separating path creation and path rendering.
> I.e. something like
>
> void create_star (int numsides)
> {
>   moveto (0, 1)
>    for (int i=0; i<numsides; i++)
>   {
>     rotate(360/numsides)
>      lineto (0, 1)
>    }
> }
...
> gsave
> create_star (10)
> fill_and_stroke_path
> grestore

That still doesn't change the fact create_start is modifying the CTM
in a way that will be visible to the caller. Imagine a family of
path-creating functions that append shapes to the current path (at the
origin, say). A use of the functions might look something like:

gsave
create_star (10)
moveto (x, y)
create_moon
fill_and_stroke_path
grestore

So what needs to be avoided here is "leaking" CTM modifications from
create_star to create_moon. In general, with the PostScript model, the
way to avoid leaking gstate modifications is with gsave/grestore. But
that's not an option for path-creating functions.

Cairo's approach (which follows PDF) of not including the path as part
of the gstate, does allow cairo_save/restore to be used within
path-creating functions.

> While I respect your decision, I am still not quite convinced why this is
> needed ;)

Hopefully, my example above is clear enough to explain my
rationale.

But at the end of the day, it is a fact that in cairo, the path is not
part of the gstate. Changing that would be break the current API, (and
API breakage is something we don't currently have any plans to do
ever).

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