Re: new arcTo parameters

On Aug 21, 2012, at 8:29 PM, Rik Cabanier <cabanier@gmail.com> wrote:

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

Typically we check for the existence of functions or properties, or run in a try-catch block.

So for drawFocusRing we simply run:
if('drawFocusRing' in context){}

However, when patching something that already exists like arcTo, we have limited options for feature testing it.

If the signature threw an error in existing implementations like: arcTo(true, etc...), then we could use a try-catch block. I believe using a Boolean in place of a number will throw an error here. I haven't checked.




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


I don't believe the Path constructor package that the WHATWG proposed is ready for implementation. It's something more appropriate for the SVG2 WG.

Still, we're all in agreement about Canvas supporting SVG path strings.


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

It's negligible in any practical terms: the relative cost of painting or running any other calculations on the arc are magnitudes higher. Additionally, the interface overhead of running a hundred lineTo commands can be larger than sending them in a single string to a processor.

As for re-use, the context.createPath() proposal makes things easy and efficient for everyone. It simply returns an opaque CanvasPath object which can be re-used. 

-Charles


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