- From: Rik Cabanier <cabanier@gmail.com>
- Date: Fri, 21 Mar 2014 13:42:32 -0700
- To: Joe Gregorio <jcgregorio@google.com>
- Cc: Justin Novosad <junov@google.com>, Dirk Schulze <dschulze@adobe.com>, Robert O'Callahan <robert@ocallahan.org>, "whatwg@whatwg.org" <whatwg@whatwg.org>
On Fri, Mar 21, 2014 at 11:52 AM, Joe Gregorio <jcgregorio@google.com>wrote: > > On Fri, Mar 21, 2014 at 12:17 AM, Rik Cabanier <cabanier@gmail.com> wrote: > >> On Thu, Mar 20, 2014 at 4:24 PM, Robert O'Callahan <robert@ocallahan.org >> >wrote: >> > An implementation can turn #2 into #1 if the paths obviously don't >> > overlap. If they might overlap, the author probably shouldn't be doing >> the >> > latter! >> > >> >> For this reason I don't particularly like the addPath API. It tricks >> authors into thinking that they will get a union of the paths. >> >> >> > TBH I don't see why authors would choose the latter approach. >> > >> >> I agree. >> 'addPath' will always cause the generation of a new path so if an author >> chooses this strange approach, the retessellation will have to happen >> again >> anyway. >> > > Agreed, the speed of Path2D comes from creating the object and then > reusing it multiple > times via fill, stroke or clip. Adding addPath to CRC2D would seem to > undermine > that and encourage non-optimal uses. > > I've wondered at times about an API that made the const-ness of paths even > more explicit: > > var b = new Path2DBuilder(); > b.moveTo(...); > b.ellipseTo(...); > var path = b.getPath2D(); > > Where path has no attributes or methods. > Agreed. That is what my shape proposal is; a immutable representation of a filled/stroked region. > > But then I think that looks too much like Java > :-)
Received on Friday, 21 March 2014 20:43:26 UTC