[cairo] Clip region problems

[Kristian Høgsberg]

On Wed, 2005-05-18 at 11:54 -0700, Keith Packard wrote:
...

This all sounds good - I'm looking into improving clipping for the PDF
and PS backends, and I was going down the path of adding more implicit
state to the surface.  This looks like a better and simpler approach.

> > * It does remove some information from the backend. It's going to 
> > be harder to optimize sequences like:
> > 
> >  - Clip to one path
> >  - Save
> >  - Clip to another path
> >  - draw
> >  - Restore
> >  - draw 
> > 
> > In the PS or PDF backend, because the surface no longer sees the
> > stack of clips. While in PS/PDF it would be possible to encode the
> > above with only two clips, with the clip serial approach, the
> > end result is:
> > 
> >  - Save
> >  - Clip to one path
> >  - Clip to another path
> >  - draw
> >  - Restore
> >  - Save
> >  - Clip to one path
> >  - draw
> >  - Restore
> 
> Yes, this looks correct.  Note that for multiple cairo_t objects to be
> usable in a single-threaded application, every cairo function call must
> appear atomic wrt the surface.  Is this possible?
> 
> > 
> > Nested clipping when drawing to paper isn't probably common enough
> > to make this a big worry.
> 
> And, if it does, we could consider making either the interface or the
> backend smarter, but I suspect that's unlikely to happen...

It shouldn't be a big problem to save the PDF or PS gstate (and thus the
clipping) for every clip operation and remember the clip serial in the
backend.  If the reestablish_clip backend function could pass in the
expected clip serial, the backend could figure out that restoring the
gstate a couple of times would be sufficient and avoid rebuilding the
clipping from scratch every time.

cheers,
Kristian