[whatwg] addPath and CanvasPathMethods
cabanier at gmail.com
Fri Mar 21 13:42:32 PDT 2014
On Fri, Mar 21, 2014 at 11:52 AM, Joe Gregorio <jcgregorio at google.com>wrote:
> 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
>> > 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
>> > 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
> 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
> 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();
> var path = b.getPath2D();
> Where path has no attributes or methods.
Agreed. That is what my shape proposal is; a immutable representation of a
> But then I think that looks too much like Java
More information about the whatwg