On Tue, Jan 29, 2013 at 8:23 PM, Tab Atkins Jr. <jackalm...@gmail.com>wrote:
> On Tue, Jan 29, 2013 at 6:10 PM, Rik Cabanier <caban...@gmail.com> wrote: > > It restores the graphics state back to the state at 'save' time and this > > includes the clip area. > > 'Clip' is a nested operation so every clip will be the intersection of > the > > existing clip area and the new one. > > > > PDF also has no initclip/resetClip and since CG is based on that model, > > maybe they didn't bother to add it. > > I can certainly see its use though (it's used quite often in PostScript) > > I find that bizarre, but I've seen weirder APIs, so whatever. > > It may still be possible without being too hacky - if the UA manually > rewinds and replays the state stack, only omitting clip() changes, it > would be the same thing. You'd have to be clever to allow the user to > restore() from that state again, though - maybe by recording the stack > of clip() operations and doing *another* rewind+replay, but this time > with the clip() calls happening again. > > My definition of "not too hacky" may be miscalibrated. > Yes, that's why I said "without significant overhead" in my original message. :-) You'd have to store all the paths to the clips + the drawing states just in case someone calls 'resetClip' in order to pull this off. Not impossible, but the CG canvas code will get very ugly.
