- From: Justin Novosad <junov@google.com>
- Date: Mon, 12 Aug 2013 16:39:44 -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 4:34 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > > 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? > Good point, I think part of the problem has to do with the fact that save is non-selective (saves all of the state). Might be worthwhile to have a selective save that pushes only a user-specified subset of the current state onto the stack. > > >> >> >>> >>> >>>> 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:40:14 UTC