[whatwg] Canvas Zero/NaN/Infinity issues

[Philip Taylor]

On 16/05/07, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 26 Mar 2007, Philip Taylor wrote:
> >
> > What should happen when Infinity or -Infinity or NaN are passed as float
> > arguments? I assume there shouldn't be a type exception since they're
> > perfectly valid floats (under the usual models of floating point
> > arithmetic), though I don't know where/if that's defined. In some cases
> > there is a logical behaviour (e.g. when translating a finite-sized
> > object by infinity, or scaling an object like rect(-10,-10,20,20) by
> > infinity then clipping it to the viewable area), but in most cases there
> > isn't (e.g. rotating by infinity, or doing anything with NaN, when the
> > output depends on those values).
> >
> > My experience with some 3d canvas code is that infinities come up in
> > naturally harmless places, e.g. having a function that scales by x then
> > translates by 1/x and wanting it to work when x=0 (which ought to draw
> > nothing, since anything it draws is zero pixels wide), and it's a bit
> > annoying to track down and fix those issues, so I'd probably like it if
> > they were harmless in canvas methods. Opera appears to silently not draw
> > anything if the transformation matrix is not finite, but Firefox throws
> > exceptions when passing in non-finite arguments.
>
> Specifically for transform(), setTransform(), scale(), and translate(),
> I've made Infinity cause the canvas to stop drawing instead of raising an
> exception. Everything else, exceptions.

I think the definitions would have to say to handle -Infinity as well
as Infinity, and say setTransform with finite arguments un-sets the
"marked as finite" flag, and maybe say that "marked as finite" is
saved/restored along with the transformation matrix.

But I'm not really convinced it's worthwhile at all, since it isn't a
trivial definition. I would assume it doesn't make the implementations
more complex (since they already have to cope with "scale(1e200,
1e200); scale(1e200; 1e200)" which is no different to "scale(Infinity,
Infinity)") but it does make the specification more complex and adds
seemingly arbitrary restrictions (e.g. why it will let me draw a
finite rectangle scaled by infinity, but not an infinite rectangle). I
don't now think these cases would be likely to come up for many
people, and exceptions are at least obvious when debugging so they're
not really that hard to fix, and simplifying the specification for
normal readers seems like a better trade-off...

-- 
Philip Taylor
excors at gmail.com