- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 12 Aug 2013 13:34:15 -0700
- To: Justin Novosad <junov@google.com>
- Cc: WHATWG List <whatwg@whatwg.org>, Stephen White <senorblanco@chromium.org>, Ian Hickson <ian@hixie.ch>
On Mon, Aug 12, 2013 at 1:24 PM, Justin Novosad <junov@google.com> wrote: > > > > 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. > Simon's example tries to work around performance problems with save/restore. Wouldn't it be better to fix that? Why is a simple save/restore so slow? > > >> >> >>> 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:34:39 UTC