Re: new arcTo parameters

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

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

Unfortunately, the browser will just call 'toNumber(true)' so you won't get
an exception.
Extra parameters are ignored too.


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

Yes. It seems like it should work for both worlds.
There would need to be a way to query it for its path information.


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

Yes.

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