W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2009

[whatwg] Canvas arcTo all points on a line

From: Philip Taylor <excors+whatwg@gmail.com>
Date: Wed, 21 Jan 2009 21:09:51 +0000
Message-ID: <ea09c0d10901211309q3e9dccddi9cb9de10b70230af@mail.gmail.com>
On Wed, Jan 21, 2009 at 2:45 PM, Philip Taylor <excors+whatwg at gmail.com> wrote:
> On Sat, Dec 27, 2008 at 9:37 AM, Dirk Schulze <vbs85 at gmx.de> wrote:
>> Hi,
>>
>> have two questions to the "all points on a line" part of canvas' arcTo.
>> A short example:
>>
>> moveTo(50,0);
>> arcTo(100,0,  0,0, 10);
>>
>> This should add a new, from p1 infinite far away, point to the subpath
>> and draw a straight line to it.
>>
>> [...]

After some discussion on IRC, it seems this part of the spec is not a
great idea.

As I understand it, the low-level graphics APIs have limited
coordinate range and rely on the "User agents may impose
implementation-specific limits on otherwise unconstrained inputs, e.g.
to prevent denial of service attacks, to guard against running out of
memory, or to work around platform-specific limitations." clause (and
common sense) to let them have undefined behaviour when people use
really large coordinate values. The infinitely-distant point required
by arcTo is a really large coordinate value, but we don't want this
case to be undefined behaviour (because it can occur with nice small
integer input values and people might accidentally use it).

Implementing the behaviour currently in the spec (with the
infinitely-distant point) is not trivial, because it requires code
unique to that special case (rather than falling naturally out of an
implementation of the rest of arcTo's behaviour) and has to be careful
to act enough like an infinitely-distance point while remaining within
the implementation limits.

And it seems like a rare edge case where people disagree on whether
the output is sensible, and nobody is really going to care what the
output is (as long as it's well defined); so it doesn't seem
worthwhile having everyone understand and implement the non-trivial
behaviour that's in the spec.

So, in the interest of having something that implementors are more
likely to converge on, I'd suggest replacing the behaviour in that
case (the "the direction from (x0, y0) to (x1, y1) is the opposite of
the direction from (x1, y1) to (x2, y2)" case) with simply drawing a
straight line from (x0, y0) to (y1, y1), which is easy and apparently
is what Safari on OS X already does. It's also the same as the other
case in that paragraph, so the whole paragraph can be collapsed to:

  "Otherwise, if the points (x0, y0), (x1, y1), and (x2, y2) all lie
on a single straight line, then the method must add the point (x1, y1)
to the subpath, and connect that point to the previous point (x0, y0)
by a straight line."

-- 
Philip Taylor
excors at gmail.com
Received on Wednesday, 21 January 2009 13:09:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:09 UTC