On Wed, Sep 1, 2010 at 11:43 AM, Chris Marrin <[email protected]> wrote: > > On Aug 31, 2010, at 6:59 PM, Kenneth Russell wrote: > >> On Tue, Aug 31, 2010 at 6:42 PM, Maciej Stachowiak <[email protected]> wrote: >>> >>> On Aug 31, 2010, at 5:29 PM, Chris Marrin wrote: >>> >>>> >>>> On Aug 31, 2010, at 5:25 PM, Kenneth Russell wrote: >>>> >>>>>>> ...Yes, I did the Google search and you're right that the term is not >>>>>>> in common usage (although I still maintain it's a completely reasonable >>>>>>> term). The reason I think it's meaningful is because it really is a >>>>>>> matrix of sorts, but a specialized one that handles only affine >>>>>>> transformations. We could call it AffineTransform, but then why not >>>>>>> call our 4x4 matrix HomogeneousTransform? I'd just like to be >>>>>>> consistent. >>>>>> >>>>>> HomogenousTransform is fine. I would also be fond of >>>>>> PerspectiveProjection. >>>>> >>>>> PerspectiveProjection is not a good name for a 4x4 matrix class. Such >>>>> a matrix might be used to represent an orthographic projection. >>>>> >>>>>> I think TransformMatrix is not a good name. It immediately raises the >>>>>> question, "what kind of transform". I also think Matrix does not need to >>>>>> be in the name. That is to some extent an implementation detail, from >>>>>> the mathematical perspective. It's more important to identify the type >>>>>> of transformation. >>>>> >>>>> I'm concerned about the route of adding a class for each kind of >>>>> transformation. It will lead to a proliferation of confusingly named >>>>> types and excess type conversion, or re-identification of the type of >>>>> transformation, when composing transformations. At least in the 3D >>>>> realm, all that is desired is one simple 4x4 matrix class. Additional >>>>> classes to represent e.g. 4x3 matrices add unnecessary complexity. >>> >>> I don't think we need a huge number, but the 2D affine transform case is >>> clearly special - it's too expensive to use a 4x4 matrix for this. >> >> Agreed. >> >>>> >>>> I agree. So, in order to appease Maciej :-) what if we keep >>>> AffineTransform as is, and change TransformationMatrix to Matrix (or >>>> Matrix4 if Matrix is too generic)? >>> >>> Is HomogenousTransform an inaccurate representation of what it does? >>> >>> The class has methods such as mapPoint, projectPoint, scale, rotate3d, >>> applyPerspective, etc. It is clearly oriented around being some sort of >>> transform, not a generic 4x4 matrix. Is it ever used to represent something >>> that is not a transform at all? Would you use this class for something >>> totally unrelated to transforms, for example if you wanted to solve a >>> system of linear equations via gaussian elimination? My expectation is that >>> you would not. >> >> I would certainly not preclude this possibility. If you look at the >> implementation of TransformationMatrix, it actually does matrix >> decomposition to extract components like rotation and perspective of a >> given transform. I could easily see the need to expose the underlying >> operations, or other operations like LU decomposition, in the public > > But I agree with Maciej that all of the public API is transformation > oriented. Even things like inverse() and transpose() have application in > doing transforms. I think it would be a stretch to use this 4x4 matrix for > general purposes. A general matrix class usually has to deal with different > dimensions, for instance. > > But I am loath to call it HomogeneousTransform, given the fact that Maciej > and I have spelled it differently (both are accepted spellings) and it will > be really hard for people to get used to spelling such an uncommon word. > > If you look at the "Uses" section of > http://en.wikipedia.org/wiki/Transformation_matrix you'll see that they > consider the term improper as well. And they have a good point. Since they > recommend the term "general transformation matrix" to distinguish it from the > more restricted "affine transformation", then simply calling it Transform > seems appropriate.
It's fine, though I'd prefer Matrix4. -Ken _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
