On Fri, Jun 6, 2014 at 12:18 PM, Kip Gilbert <kgilb...@mozilla.com> wrote:
> Hello, > > From a game programmer's perspective, isIdentity would normally be used to > cull out work. In these cases, it is expected that isIdentity will return > true only when the matrix is exactly equal to the identity matrix. Due to > the nature of floating point, the isIdentity will only likely be true when > it has been initialized or assigned identity directly. This is what occurs > in existing game / math libraries. > Yes, this is why storing it as an internal flag is the correct solution. > If we allow some amount of tolerance in the comparison, the issue is of > how much tolerance is right for a particular application. One application > may benefit from having small amount of variance as it may be rotating > items around a pivot that is close to their origins with units that are > screen space coordinates; however, another application may use a pivot / > origin that has a real-world relation to the objects represented in a > scene. The same amount of variance that would allow an unnoticeable > sub-pixel difference in the first case would result in an object not > appearing at all in the second case. IMHO, acceptable level of tolerance > is something that the platform should never dictate and that users of the > library would never expect. It is considered safe to error on the side of > returning false but never safe to return true when the value is not exactly > identity. > > Another use case is physics calculation. The vast majority of simulated > objects will be at their resting position until they are hit by a collider > in which case their transform becomes non-identity. The moving objects > live for a short time until they "respawn" in which case their transform is > set back to the origin with the assignment of an identity matrix. > Expensive calculations such as IK (Inverse Kinematics) chains are executed > only on the objects that are not at rest and thus are transformed by a > matrix that is not identity. > > tl;dr.. I would only see real-world benefit in a simple IsIdentity > function which returns true only when the matrix is exactly identity. I agree. At this point, it's clear that isIdentity() is too confusing and doesn't do what its name implies. Let's go with roc's proposal and replace the API with 'maybeHasTransform'. > > It is a good point that checking all 16 elements every time is costy. But >> that is exactly what authors would expect the UA to do. >> >> I still don’t buy the argument with unexpected results though. We never >> can guarantee exact results. 1 divided by 3 doesn’t give exact results but >> at least interoperable results as long as platforms follow IEEE. This is >> not the case for trigonometric functions. It is not possible to guarantee >> that sin(Math.PI/3) is the same on all platforms since implementations vary >> across platforms. This of course affects DOMMatrix when one uses rotate. So >> none of the values can be guaranteed to be interoperable across all >> platforms. That means that isIdentity might not be guaranteed to give exact >> results either. And this usually is fine. If isIdentity does return false, >> well then the engine has to do a bit more work and can’t return earlier… >> That is what isIdentity is used for anyway. Make sure that engines don’t do >> unnecessary transformations. >> >> It is good that DOMMatrix can be extended by users to add this basic >> functionality that all drawing engines and browser engines use under the >> hood already. >> >> Greetings, >> Dirk >> >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
