Intent to Implement and Ship: ellipse in <canvas>

[Hwang, Dongseong]

Primary eng/PM emails

dongseo...@intel.com, sche...@chromium.org

 

Spec

Ellipse in <canvas> Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-ellipse

 

Summary

Canvas v5 API adds a new path segment type: ellipse

 

Motivation

<Canvas> supports arc API, so Web developers expect <Canvas> can support ellipse API. If we implement Canvas v5, Blink can support ellipse API. It is an expectable and benign API change.

 

Compatibility Risk

whatwg addressed Canvas v5 at 28.Mar.2012: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035239.html

There were not any objections against ellipse API.

 

There were not any Browser to support Ellipse API at 23.Jan.2013. http://www.rgraph.net/blog/2013/january/html5-canvas-ellipse.html

 

Although there are not any Browsers supporting this API, I think we can support Ellipse API, because this API is backward compatible, and there are not any objections against this API.

 

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=130260

 

Row on feature dashboard?

No, I think it is a benign and “small change”. I’m open to your suggestions. :)

 

Requesting approval to ship?

Yes, this API change is small and backward compatible.

 

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[dongseo...@intel.com]

 

Row on feature dashboard?

No, I think it is a benign and “small change”. I’m open to your suggestions. :)

 

There already is the row related to this change. Search "Canvas".

I think my suggestion belongs to the row because the row is quite general for Canvas API.

Br, DS

[Eric Seidel]

To be clear, this is not just completely syntactic sugar for arc(),
but rather this is new functionality for CanvasRenderingContext2D
(with which arc() could in turn be implemented?).

[Hwang, Dongseong]

Hi,

 

Good question. I think the WhatWG spec is clear although the spec is not kind.

 

The sentence is as follows:

----

If the anticlockwise argument false and endAngle-startAngle is equal to or greater than 2π, or, if the anticlockwise argument is true and startAngle-endAngle is equal to or greater than 2π, then the arc is the whole circumference of this ellipse.

 

Otherwise, the arc is the path along the circumference of this ellipse from the start point to the end point, going anti-clockwise if the anticlockwise argument is true, and clockwise otherwise. 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.

---

 

The first sentence deals with the case that angle difference is more than 2pi with proper direction. I think it is clear.

“Proper direction” means if the anticlockwise argument false, endAngle-startAngle is positive, and if the anticlockwise argument true, startAngle-endAngle is positive.

 

The second sentence deals with the case that both angle difference is less than 2pi with proper direction, and angle difference is more than 0 with improper direction. In the case, we should draw the path along the circumference of this ellipse from the start point to the end point in the direction of the anticlockwise argument.

 

The sentence (“Since the points are on the ellipse…..”) that made you confusing is just additional explanation for the second sentence. This sentence just clarifies that when we draw the path along the circumference of this ellipse from the start point to the end point, it is impossible that the angle difference is greater than 2pi. The reason that the sentence says additional explanation is that dealing with more than 2pi is the role that the first sentence should play.

 

If I’m not correct, please let me know.

 

Br, DS Hwang

 

From: Rik Cabanier [mailto:caba...@gmail.com]
Sent: Monday, April 29, 2013 8:21 PM
To: Hwang, Dongseong
Subject: Re: [blink-dev] Intent to Implement and Ship: ellipse in <canvas>

 

The WhatWG spec is unclear about certain edge cases.

 

For instance, this line:

If the anticlockwise argument false and endAngle-startAngle is equal to or greater than 2π, or, if the anticlockwise argument is true and startAngle-endAngle is equal to or greater than 2π, then the arc is the whole circumference of this ellipse

which is followed by this: 

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.

 

This sounds like a contradiction. Are you supposed to draw with the angles or the points on the arc. (It seems that first sentence should be eliminated or the angles should be normalized first)

[dongseo...@intel.com]

Hi, Thank you for your good clarification.

In https://codereview.chromium.org/14298022/ , I implemented ellipse using arc and transform.

Now I focused on readability rather than speed. We will be able to optimize ellipse if needed. (e.g. adding the ellipse primitive in skia, or adding the fast ellipse logic in Path.cpp)

Br, DS

[Tom Hudson]

On Tue, Apr 30, 2013 at 8:36 AM, <dongseo...@intel.com> wrote:

Hi, Thank you for your good clarification.

In https://codereview.chromium.org/14298022/ , I implemented ellipse using arc and transform.

Now I focused on readability rather than speed. We will be able to optimize ellipse if needed. (e.g. adding the ellipse primitive in skia, or adding the fast ellipse logic in Path.cpp)

I think a rotation transform + SkCanvas::drawArc() is already a primitive implementation in Skia of Canvas2d.ellipse()? Or is there some detail (modulo math to convert start/end angle to start angle/sweep) I'm missing?

Tom

[Rik Cabanier]

I guess that makes sense although it's super confusing. The first sentence implies that you draw following the rotation which is not the case.

Why not simply call them points on the ellipse and draw the ellipse between them and if the points coincide, you always draw a full ellipse.

[Eric Seidel]

There was some concern brought at the API OWNERS meeting today that we
may be slightly premature in shipping this. This is exactly the kind
of spec where we'll implement one argument-ordering and a later
version of the spec will change it. :)

But the belief was that risk was rather small.

I would encourage you to continue to communicate with other vendors
about our intent to ship this in Blink.

LGTM on behalf of the API OWNERS for shipping (no LGTM needed for implementing).

[dongseo...@intel.com]

Thank you for very quick decision. I think API OWNERS work very hard :)

As I understand, after one OWNER give LGTM for implementing, this change can be shipped. Am I right?

I have no experience to communicate with other vendors yet. I'll try via this opportunity.

[dongseo...@intel.com]

Yes, SkCanvas::drawArc() is already existing. You don't miss anything :) We can implement ellipse for <canvas> using transform + arc in either skia or Path.h. And I think both performance would be the similar.

The optimization that I suggested in previous comment is implementing ellipse using only bezier curves without transform. It will be complex, so I said that we will optimize if needed.

[Ojan Vafai]

On Tue, Apr 30, 2013 at 11:45 AM, <dongseo...@intel.com> wrote:

Thank you for very quick decision. I think API OWNERS work very hard :)

As I understand, after one OWNER give LGTM for implementing, this change can be shipped. Am I right?

Correct.

[dongseo...@intel.com]

On Tuesday, April 30, 2013 6:30:27 PM UTC+3, Rik Cabanier wrote:

I guess that makes sense although it's super confusing. The first sentence implies that you draw following the rotation which is not the case.

Why not simply call them points on the ellipse and draw the ellipse between them and if the points coincide, you always draw a full ellipse.

I don't fully catch up your explanation. However, I try to show counter examples.

Three below examples should not draw anything.

Ex1 > start angle:0, end angle:0

Ex2 > clockwise, start angle:2pi, end angle: 0

Ex3 > anticlockwise, start angle:0, end angle: 2pi

[Eric Seidel]

More specifically, I was speaking on behalf of all the OWNERS (as we
agreed this morning in an in-person meeting).

Normally via email you would see 3 separate LGTMs from OWNERS (and
then we could have skipped our in-person meeting!).

[dongseo...@intel.com]

Hi, canvas ellipse is implemented and shipped.

https://code.google.com/p/chromium/issues/detail?id=130260

Thank Stephen, junov, alph, wiltzius, Eric, Ojan, Tom and Rik for your sincere help!