Re: new arcTo parameters

On Tue, Aug 21, 2012 at 5:33 PM, Charles Pritchard <chuck@jumis.com> wrote:

> On 8/21/2012 2:25 PM, Rik Cabanier wrote:
>
>>
>> While looking through the new spec, I noticed that arcTo now takes 2
>> optional commands: RadiusY and rotation.
>>
>>
>> SVG has 2 more parameters that give you even more control (see the spec
>> for details). Would it make sense to add those as well?
>>
>> 1: http://www.w3.org/TR/SVG/**paths.html#**PathDataEllipticalArcCommands<http://www.w3.org/TR/SVG/paths.html#PathDataEllipticalArcCommands>
>>
>
>
> We've been using curves instead of arcTo, on my projects.
> I'm fairly neutral on this.
>
>
> Is there an appropriate way to feature test that changes to arcTo are
> present/supported?
>

I don't think so. I believe that that is a major problem with Canvas.
In an object oriented world, you would request a particular interface but
I've been told that is not how you do things in the browser.


>
> I do like the idea of arcTo being even closer to SVG.
> There seems to be full consensus that an item like: context.svgPath('A rx
> ry x-axis-rotation large-arc-flag sweep-flag x y') ought to be supported.
>

You're correct. Canvas should support the SVG Path operator through the
Path constructor that takes a string. [1]


> We could just have that SVG string path method without altering the
> current signature of methods.
>
> Benefits there are continued stability of the API, compatibility with
> existing distributions, and a focus on supporting SVG paths through a
> single string-based method.


Aren't strings slower because of the VM thrashing or is that negated by
having fewer DOM calls?
I'm tempted to have API parity with SVG, especially for the Path object.

Rik

1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path