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

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

From: Stephen White <senorblanco@chromium.org>
Date: Mon, 12 Aug 2013 21:05:05 -0400
Message-ID: <CAPeKFTi+WfPqK1E8SfxrW3+qwBHDeYkZk2JbWtDFB3mSAs98=g@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: Justin Novosad <junov@google.com>, Simon Sarris <simon.sarris@gmail.com>, Ian Hickson <ian@hixie.ch>, WHATWG List <whatwg@whatwg.org>
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

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