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 <caban...@gmail.com> wrote: > > > On Mon, Aug 12, 2013 at 2:26 PM, Justin Novosad <ju...@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.sar...@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. >>> >>> >>> >>> >>> >>> >> >