[Cairo] Suggestion for replacing cairo_copy with set_gstate.

[Keith Packard]

Around 11 o'clock on Sep 26, Carl Worth wrote:

> I think the persistent status is an important feature, (which reminds
> me I was planning to send a message to advertise this feature better).

In which case eliminating application usage of multiple cairo_t objects 
seems like a valuable goal.

> Can't we really do both? The proposal was to maintain the stack, but
> expose the cairo_gstate_t object with a couple of new functions to
> manipulate the gstate on the top of the stack:

Yes, we can do both, but it exposes two objects instead of one; I guess 
that would be OK if we can explain what the differences are...

> That would allow us to maintain the stack and persistent status. And I
> don't see save/restore set_gstate/get_state as redundant, (PostScript
> provides the same).

PostScript provides save/restore because local variables are a huge pain in 
PostScript; using stacks is a natural way to avoid that.  Otherwise, set/
get are sufficient.

However, once we admit that we want the cairo_t to hold the state and 
status separately, having a stack of states inside the cairo_t is not a 
significant additional semantic burden.

> The biggest drawback I see to this approach is that Cairo will be
> exposing two different state objects, (cairo_t and cairo_gstate_t).  

As long as we describe cairo_t as a status value along with a stack of
cairo_gstate_t objects, I think we can avoid confusing things too much.

Let's do it this way; it's clearly better than cairo_copy and matches the 
postscript functionality pretty closely.

-keith