[whatwg] addPath and CanvasPathMethods

[Rik Cabanier]

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
>> >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
>

:-)