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

If this is strictly a performance issue, then we definitely should fix that
before adding new API, IMHO. It would be great to get some reduced test
cases where save()/restore() is a bottleneck.

(Incidentally, we did some performance fixes recently for setFont() in
Chrome.)

Stephen



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

>
>
> On Mon, Aug 12, 2013 at 2:26 PM, Justin Novosad <junov@google.com> wrote:
>
>> Ok, so here is a simple proposal:
>>
>> IDL:
>> enum CanvasSaveMode { "all", "transform", "clip", "transform-and-clip" };
>> save(optional CanvasSaveMode mode);
>>
>> Modes:
>> all: save the entire rendering context state
>> transform: save only the current transform
>> clip: save only the current clip
>>
>> if mode is not specified, the entire context state is saved (for backward
>> compatibility)
>>
>> The restore method's interface does not change. It restores whatever
>> state was saved by the matching save call.
>>
>
> I wasn't really thinking about a new API surface :-)
> Can't this be fixed under the hood? The tricks that Simon is doing, could
> be done by the browser itself.
>
> If not, this proposal looks reasonable (if you turn it into a dict like
> Tab says).
>
>>
>> On Mon, Aug 12, 2013 at 4:56 PM, Simon Sarris <simon.sarris@gmail.com>wrote:
>>
>>> > Good point, I think part of the problem has to do with the fact that
>>> save
>>> > is non-selective (saves all of the state).
>>>
>>> Yes, since save() and restore() save and restore everything, it creates
>>> the side effect of needing to set ctx.font/fillStyle/strokeStyle more often
>>> than otherwise, which are slow to set, probably because of some CSS parser
>>> activity, but I'm not wise enough to know.
>>>
>>> If there was merely a way to save and restore the context, or perhaps
>>> some other subset of state, that would probably work nicely too.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Received on Tuesday, 13 August 2013 01:05:29 UTC