- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 10 Mar 2014 11:14:59 -0700
- To: Joe Gregorio <jcgregorio@google.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>
On Mon, Mar 10, 2014 at 11:07 AM, Joe Gregorio <jcgregorio@google.com>wrote: > > > > On Mon, Mar 10, 2014 at 2:02 PM, Rik Cabanier <cabanier@gmail.com> wrote: >> >> >> What are you not sure about? >> >> The current Path2D interface might be unacceptably slow under certain >> circumstances and there's currently no way for authors to work around >> this. >> There has to be a hint. If not, I don't see a way that firefox will ship >> this. >> > > What part is slow, the decoding and re-encoding, or is just always the > encoding step > that is slow? > It's decoding/re-encoding of an already constructed path. > I thought the speed of Path2D came from the reuse, that is, that the build > cost wasn't > a big concern because the speed came from reusing that same object over > and over > at up to 60fps? > Yes. The concern is that the re-encoding will happen every time you use the path. We could code it in such a way that the path is retargeted when it's used. It's a bit strange since fill and stroke are not supposed to "change" the path.
Received on Monday, 10 March 2014 18:15:26 UTC