[whatwg] addPath and CanvasPathMethods

[Joe Gregorio]

On Fri, Mar 21, 2014 at 12:17 AM, Rik Cabanier <cabanier at gmail.com> wrote:

> On Thu, Mar 20, 2014 at 4:24 PM, Robert O'Callahan <robert at 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.

But then I think that looks too much like Java

 -joe