On 2014-06-07, 9:38 PM, Benoit Jacob wrote:
2014-06-07 12:49 GMT-04:00 L. David Baron <dba...@dbaron.org <mailto:dba...@dbaron.org>>: On Monday 2014-06-02 20:45 -0700, Rik Cabanier wrote: > - change isIdentity() so it's a flag. I'm a little worried about this one at first glance. I suspect isIdentity is going to be used primarily for optimization. But we want optimizations on the Web to be good -- we should care about making it easy for authors to care about performance. And I'm worried that a flag-based isIdentity will not be useful for optimization because it won't hit many of the cases that authors care about, e.g., translating and un-translating, or scaling and un-scaling. Note that the current way that isIdentity() works also fails to offer that characteristic, outside of accidental cases, due to how floating point works. The point of this optimizations is not so much to detect when a generic transformation happens to be of a special form, it is rather to represent transformations as a kind of variant type where "matrix transformation" is one possible variant type, and exists alongside the default, more optimized type, "identity transformation". Earlier in this thread I pleaded for the removal of isIdentity(). What I mean is that as it only is defensible as a "variant" optimization as described above, it doesn't make sense in a _matrix_ class. If we want to have such a variant type, we should call it a name that does not contain the word "matrix", and we should have it one level above where we actually do matrix arithmetic. Strawman class diagram: Transformation / | \ / | \ / | \ / | \ Identity Matrix Other transform types e.g. Translation In such a world, the class containing the word "Matrix" in its name would not have a isIdentity() method; and for use cases where having a "variant type" that can avoid being a full blown matrix is meaningful, we would have such a variant type, like "Transformation" in the above diagram, and the isIdentity() method there would be merely asking the variant type for its type field.
I agree with this approach, but I don't think that we want to expose this division (directly) to the Web. It would be great to see these divisions used internally to optimize: composing translations gives another translation, etc.
Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
