[whatwg] remove resetClip from the Canvas 2D spec

Justin Novosad junov at google.com
Mon Aug 12 13:39:44 PDT 2013


On Mon, Aug 12, 2013 at 4:34 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
> On Mon, Aug 12, 2013 at 1:24 PM, Justin Novosad <junov at google.com> wrote:
>
>>
>>
>>
>> On Mon, Aug 12, 2013 at 2:15 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad <junov at google.com> wrote:
>>>
>>>> On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson <ian at 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.
>>
>>
>



More information about the whatwg mailing list