[whatwg] canvas 2d's ellipse
ian at hixie.ch
Wed Oct 16 14:49:25 PDT 2013
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.
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg