Re: [whatwg] remove resetClip from the Canvas 2D spec

On 1/29/13 6:10 PM, Rik Cabanier wrote:
>
>
> On Tue, Jan 29, 2013 at 5:27 PM, Tab Atkins Jr. <jackalmage@gmail.com 
> <mailto:jackalmage@gmail.com>> wrote:
>
>     On Tue, Jan 29, 2013 at 5:00 PM, Rik Cabanier <cabanier@gmail.com
>     <mailto:cabanier@gmail.com>> wrote:
>     > All,
>     >
>     > we were looking at how resetClip [1] could be implemented in WebKit.
>     > Looking over the Core Graphics implementation, this feature can't be
>     > implemented without significant overhead. I also found an email
>     from 2007
>     > where Maciej states the same concern. [2]
>     >
>     > Since no browser has implemented it, can it be removed from the
>     spec?
>     >
>     > Rik
>     >
>     > 1:
>     >
>     http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-resetclip
>     > 2: http://permalink.gmane.org/gmane.org.w3c.whatwg.discuss/10582
>
>     It seems kinda bizarre that it's hard to reset, given that you can
>     remove it by saving and restoring context.
>
>     It seems bizarre that it would *ever* be hard to reset, to be honest.
>     That's just plain weird.  I mean, just what *does* CoreGraphics do
>     with restore()?
>
>
> 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)

There seem to be a good 8 years of discussion about this issue.

I tend toward the side of least-common denominator, and in this case, it 
means letting go resetClip.

If we're departing from that, and in some way we are, that's another 
situation.
We can create trees within implementations that do re-build state if 
needed. I just prefer to go the easy and direct route, and force some of 
the difficult management onto the people using the APIs there are 
difficulties involved, but overall, as long as speed and expressiveness 
are available, we can handle the rest through more code.



-Charles