W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

Re: [whatwg] Canvas and Paths

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 17 Mar 2014 19:37:53 -0700
Message-ID: <CAGN7qDDBaPwi3uAKZUGvLVzXgYQF13sj5OBXSWCkjtKF+G3VRg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
>
> On Mon, 10 Mar 2014, Tab Atkins Jr. wrote:
> >
> > This is also my question.  Given that generating a path for a particular
> > context isn't a magic bullet *anyway* (because the details of the
> > context can change), I don't understand why caching isn't the answer.
>
> On Mon, 10 Mar 2014, Rik Cabanier wrote:
> >
> > At usage time, the path could be retargeted to a new backend.
>
> If the backend changes, knowing the backend at creation time doesn't help.
>
> If it doesn't, then the cost seems to be the same either way.
>
>
> > I don't think that should be done as a cached copy since that would
> > require too many resources. I will see if this is an acceptable solution
> > for mozilla.
>
> How many resources could a path possibly take?
>
>
> On Mon, 10 Mar 2014, Justin Novosad wrote:
> >
> > Isn't caching ideal for that situation? In the case of re-targeting, you
> > can either replace the cached encoding, or append the new encoding to a
> > collection of cached encodings.  Both of those options seem more
> > effective than to stick to an encoding type that was baked-in at
> > construction time. It may also be great to have a heuristic to chose
> > whether to discard the previously cached re-encoding. Something like: if
> > we are re-encoding because the destination backing type changed due to a
> > resize, then discard previous encodings; if re-encoding because the path
> > is drawn to multiple canvases, then retain multiple cached encodings.
>
> That makes sense to me.
>

FYI
The Firefox people agreed to a solution that retargets the path if its
backend doesn't match with the canvas context backend.
There's no need to change to current API.
Received on Tuesday, 18 March 2014 02:38:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC