On Wed, Jun 4, 2014 at 12:21 AM, Dirk Schulze <dschu...@adobe.com> wrote:
>
> On Jun 4, 2014, at 12:42 AM, Rik Cabanier <caban...@gmail.com> wrote:
>
> >
> >
> >
> > On Tue, Jun 3, 2014 at 3:29 PM, Robert O'Callahan <rob...@ocallahan.org>
> wrote:
> > On Wed, Jun 4, 2014 at 10:26 AM, Rik Cabanier <caban...@gmail.com>
> wrote:
> > That would require try/catch around all the "invert()" calls. This is
> ugly
> > but more importantly, it will significantly slow down javascript
> execution.
> > I'd prefer that we don't throw at all but we have to because SVGMatrix
> did.
> >
> > Are you sure that returning a special value (e.g. all NaNs) would not
> fix more code than it would break?
> >
> > No, I'm not sure :-)
> > It is very likely that people are just calling invert and don't check
> for the exception. Returning NaN might indeed make thing more stable.
> >
> > I think returning all NaNs instead of throwing would be much better
> behavior.
> >
> > I completely agree.
> > Going with Benoit's suggestion, we can change the idl for invert to:
> > bool invert();
> > and change inverse to return a matrix with NaN for all its elements.
>
> I don’t think that this is really getting the point. You seem to have the
> assumption that this is the most common pattern:
>
> if (matrix.isInvertible())
> matrix.invert();
>
> It isn’t in browser engines and I don’t think it will be in web
> applications. The actual use case would be to stop complex computations and
> graphical drawing operations right away if the author knows that nothing
> will be drawn anyway.
>
> function drawComplexStuff() {
> if (matrix.isInvertible())
> return; // Stop here before doing complex stuff.
> … complex stuff...
> }
>
I think the argument is that you just do the complex logic regardless if
the matrix is invertible.
I did some sleuthing on github [1] on how people use 'inverse' and could
find very few places that actual check if a matrix is invertible. It seems
the vast majority don't catch the exception so the program crashes.
I only found 2 instances where invertibility is checked.
One is in Google's closure library [2] and the other is in another library.
I could not find any instances of people actually calling these methods.
mozilla's codebase doesn't seem to do anything special for non-invertible
matrices. WebKit does what you describe though (mainly in the canvas code)
Given this, let's stay with the decision to leave 'isInvertible()'
People can polyfill it and we can always add it later if needed.
> There was an argument that:
>
> if (matrix.isInvertible())
> matrix.invert();
>
> would force UAs to compute the determinant twice. Actually, UAs can be
> very smart about that. The determinant is a simple double. It can be stored
> and invalidated as needed internally. (If it even turns out to be an issue.)
> I don't think that the argument about numerical stability counts either.
> If the determinant is not exactly 0, then the matrix is invertible. It
> doesn’t really matter if it is a result of numerical precision or not.
>
Caching the determinant will be much slower because it will force us to add
an internal flag that will need to be checked every time you change the
matrix.
It would also make the DOMMatrix object bigger by the size of the flag and
a double.
> To get back to
>
> bool invert()
> DOMMatrix inverse()
>
> invert() does a matrix inversion in place. So it is not particularly
> useful as a simple check for singularity.
> inverse() currently throws an exception. If it doesn’t anymore, then
> authors need to know that they need to check the elements of DOMMatrix for
> NaN. On the other hand, relying on exception checking isn’t great either.
> Both is making the live more difficult for authors.
>
> So I am not arguing that inverse() must throw and I dot argue that
> invert() should return a boolean. Changing this is fine with me. I am
> arguing that isInvertible() makes a lot of sense. Why wouldn’t it on the
> web platform if it is useful in our engines? determinant() is a way to
> check for singularity. Having either determinant() or isInvertible() or
> both makes a lot of sense to me. determinant() will be used internally a
> lot anyway. Being smarter and store the result of determinant() should
> solve some of the concerns.
>
1:
https://github.com/search?l=JavaScript&p=1&q=svg+matrix+inverse&ref=advsearch&type=Code
2: https://github.com/google/closure-library
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
