[whatwg] canvas 2d's ellipse

[Ian Hickson]

On Tue, 30 Apr 2013, Rik Cabanier wrote:
>
> 1. Why are most of the [ellipse] parameters not optional?

It's supposed to be the same as arc(), but with radius split into radiusX 
and radiusY, and with the addition of the rotation argument.


> So, if you want to draw a simple circle, you have to supply 8 parameters,
> even though only 3 are needed.

If you just want a circle, you can use arc().


> All other calls have anticlockwise optional, why not ellipse?

Probably just an oversight. I've made this consistent with arc().


> 2. when is an ellipse closed?
> It's not clear from the prose if there is ever a 'closepath'. So, if you
> have square end caps, you will see a discontinuity unless you call
> 'closepath'.

It works the same as arc(). I'm not really sure what you're asking here.


> 3. the following lines are somewhat confusing:
> 
> If the anticlockwise argument false and endAngle-startAngle is equal to or
> greater than 2π, or, if the anticlockwise argument is true
> andstartAngle-endAngle is equal to or greater than 2π, then the arc is the
> whole circumference of this ellipse.
> 
> and:
> 
> Since the points are on the ellipse, as opposed to being simply angles from
> zero, the arc can never cover an angle greater than 2π radians.
> 
> Why not simply say that the angles define the points on the ellips and draw
> the arc between them? That seems more clear.

It means something different. For example, 0..3π is supposed to cover the 
whole arc, but if we define things as points on the ellipse, it would be 
half an arc.


On Tue, 30 Apr 2013, Rik Cabanier wrote:
>
> I think the API should look like this:
> 
> void ellipse(unrestricted double x, optional unrestricted double y,
> unrestricted double radiusX, optional unrestricted double radiusY, optional
> unrestricted double rotation, optional unrestricted double startAngle,
> optional unrestricted double endAngle, optional boolean anticlockwise);
> 
> with the following behavior:
> - if radiusY is omitted, it's the same as radiusX
> - if rotation is omitted, it's equal to 0
> - if startAngle is omitted, it's equal to 0
> - if endAngle is omitted, it's equal to 0
> - if anticlockwise is omitted, it's equal to false

We could do this, sure. How much do people want something like this? Does 
anyone else think it's a good idea?


> startAngle and endAngle always refer to points on the circle. If they 
> coincide, the end result is a full circle (with a closepath).

We can't change arc()'s behaviour. ellipse() should behave as close to 
arc() as possible, for sanity. (I wouldn't have introduced it at all, if 
there was some sane way to overload arc() to add radiusY and rotation. But 
there isn't, really.)


On Tue, 30 Apr 2013, Rik Cabanier wrote:
> 
> I think the exception on negative radius should also be removed.

What would a negative radius mean?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'