- From: Justin Novosad <junov@google.com>
- Date: Mon, 12 Aug 2013 16:24:54 -0400
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: WHATWG List <whatwg@whatwg.org>, Stephen White <senorblanco@chromium.org>, Ian Hickson <ian@hixie.ch>
On Mon, Aug 12, 2013 at 2:15 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > > On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad <junov@google.com> wrote: > >> On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson <ian@hixie.ch> wrote: >> >> > >> > This is a quite widely requested feature. What should we do to address >> > this request instead? >> > >> > >> What if resetClip restored the clip to what it was at the save call that >> created the current state stack level? >> In other words, restore the clip, but without popping it off the >> save/restore stack. >> > > It would be good to hear specific use cases for 'resetClip' so we can make > that call. > I think your proposal could be made to work with Core Graphics. > Agreed. I only had Simon Sarris's use case in mind (app uses reset instead of save/restore for perf reasons) when I wrote that. > > >> Also, resetMatrix could be defined to do the same. > > > Is that API defined somewhere? > Sorry, I meant "resetTransform". It is currently unimplemented in Blink.
Received on Monday, 12 August 2013 20:25:21 UTC