W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

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

From: Simon Sarris <simon.sarris@gmail.com>
Date: Fri, 9 Aug 2013 16:31:07 -0400
Message-ID: <CAA5isUb9xx0EamnM8P76JwGmQHCkHZ3mq06PksPjaLKQHuESFQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: WHATWG List <whatwg@whatwg.org>, Stephen White <senorblanco@chromium.org>
I originally opened this bug/request for performance reasons, since I try
to avoid all use of save() and restore() on the context. As a refresher
resetting any piece of context state by itself is possible except for
clipping regions.

I do see Rik's point about the mess a resetClip() function would make with
save() and restore().

It also seems, if I am reading Rik's reasoning right (and its totally
possible I'm wrong here), that such a problem would not exist if we had a
setClip() function instead.

As an alternative I would propose something like setClip() or setClip(path)
(with the former working on the current path, just like
clip()/fill()/stroke() does).

The reason we need something else is because clip() can only ever get
smaller, since it takes the intersection of the current clipping region and
the current path. setClip() would not take the intersection, instead it
would override the current clipping region with the current path (or given
path if you prefer).

This setClip would still allow de-facto "resets" of the clipping state by
doing:

// most likely the transform would also be reset right before this, if it
was not already identity
// ctx.setTransform(1, 0, 0, 1, 0, 0);
ctx.beginPath();
ctx.rect(0, 0, canvas.width, canvas.height);
ctx.setClip();

Would such a set up make it easier to accommodate save and restore? (which
many people using this would not be using anyway). I'd expect it to be
similar to setTransform() in that regard, but maybe not.

More generally, does this seem more reasonable, or feasible?





On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Fri, 9 Aug 2013, Stephen White wrote:
> >
> > Although Skia could support resetClip() via SkRegion::kReplace_Op, it's
> > problematic for the API in general, and I think we should avoid it.
> >
> > In particular, it makes it impossible to place a display list (SkPicture
> > in Skia parlance) inside a parent display list containing a clip and be
> > assured that the child will not draw outside the given region, since the
> > child display list can always resetClip() its way out of the parent's
> > clip. It probably also prevents culling optimizations for the same
> > reason.
> >
> > For example, if one used Skia to draw the entirety of a browser UI
> > including chrome and content, the resetClip() inside the web page
> > contents would overwrite the browser UI. Obviously we don't do that in
> > Chrome, but it goes some idea of the problem at the API level.
>
> This is a quite widely requested feature. What should we do to address
> this request instead?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Friday, 9 August 2013 20:31:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC