On Jun 6, 2014, at 10:23 PM, Rik Cabanier <caban...@gmail.com> wrote:
> 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’. You can not say you agree and turn the comment around by 180 degree (or PI). The comment was: “" tl;dr.. I would only see real-world benefit in a simple IsIdentity function which returns true only when the matrix is exactly identity. “" This is exactly what I wrote. Greetings, Dirk > > >> >> 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
