[whatwg] canvas 2d's ellipse

[Rik Cabanier]

On Tue, Aug 20, 2013 at 3:46 PM, Ian Hickson <ian at hixie.ch> wrote:

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

OK. What if you want to draw a simple ellipse?


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

True. arc() has the same issue.
Here's an example of the issue: http://jsfiddle.net/2N85k/2/
Because the stroke is using square caps, you can't draw a circle or an
ellipse unless you do a closePath.

Chrome is doing an implicit closePath if start and end angle meet, but none
of the other browsers do.,


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

the spec does say 'Since the points are on the ellipse' hence my confusion
:-)


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

Yes.
However the spec should be clearer on what happens if the arc is 2 π for
arc and ellipse.
Chrome believes that case should have a 'closePath' which seems reasonable.
Maybe someone on that team can tell us if this was intentional.


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

Either treat it as zero, or use the absolute value. Avoiding exceptions
will make web apps more robust.