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.
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.
- Kip
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
