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

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 12 Aug 2013 13:34:15 -0700
Message-ID: <CAGN7qDDqVb7OQxH-R+pyQL0ZrnPKxzpVTT-oDzgT+JyuY7MMPg@mail.gmail.com>
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

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