[whatwg] canvas 2d's ellipse

[Ian Hickson]

On Tue, 17 Sep 2013, Rik Cabanier wrote:
> On Tue, Sep 17, 2013 at 1:27 PM, Ian Hickson <ian at hixie.ch> wrote:
> >
> > Dramatically simplifying the situation here, we're saying that the 
> > available options are:
> >
> > A: All buggy applications fail to compile, because of static checking.
> >    Cost to fix the bugs is low.
> >
> > B: All buggy applications break entirely when edge cases are hit.
> >    Cost to fix the bugs is moderate.
> >
> > C: Some buggy applications break entirely when edge cases are hit.
> >    Some buggy applications have data corruption!
> >    Some buggy applications have merely graphical artefacts.
> >    Cost to fix the bugs is high.
> >
> > I think option A is vastly superior, but since that's not an option, 
> > option B is preferable to option C.
> 
> You are speaking as a developer, not as a user of a web application. 

Usually people accuse me of the opposite, so it's nice to hear. :-)

However, I don't think there's a huge difference in this case. The only 
difference is that with B (vs C) there's less likely to be data corruption 
(good for the user!), and more likely to be apps that break entirely 
rather than just with graphical artefacts (bad for the user). I think it 
more or less balances out. The benefit, however, is that the bugs are more 
likely to be fixed quicker with B than with C.


> Browser could offer a 'debug' more where they break on bad calls or 
> output messages to the console. Once it's 'released', the runtime should 
> be permissive.

That would be an interesting idea. We don't currently have anything like 
this in the platform.

heycam, what do you think of such a feature? Basically, "asserts" in the 
APIs, which would be catchable in a debugger, but wouldn't actually block 
execution if there's no debugger around?


On Wed, 18 Sep 2013, Robert O'Callahan wrote:
> 
> I think our decision to make 2D canvas methods [LenientFloat] (choosing 
> C over B) was a good one because "muddling on through" in the case of a 
> transient singularity that will likely only produce a transient 
> rendering error seems like a good cost-benefit tradeoff. So we need to 
> consider the likely impact of the bug; transient graphical artifacts are 
> relatively low impact.

Agreed that this is something to consider on a case-by-case basis.


> Also I think we should consider whether the bad behavior is 
> deterministic and hence likely to be detected during testing. When it 
> isn't (and can't be made so!), it makes more sense for implementations 
> to be lenient (choose C over B), since then it's more likely the impact 
> of the bug will fall on users as much or more than developers and the 
> cost of fixing the bug is high no matter what we do.

Right.

In this particular case (negative radii) it seems pretty deterministic.


My main point with the A/B/C thing was that we don't uniformly pick C. We 
do sometimes pick C where it makes sense; usually we pick either B or C.

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