On Tue, Aug 31, 2010 at 4:22 PM, Maciej Stachowiak <m...@apple.com> wrote: > > On Aug 31, 2010, at 3:59 PM, Chris Marrin wrote: > >> >> On Aug 31, 2010, at 3:43 PM, Kenneth Russell wrote: >> >>> On Tue, Aug 31, 2010 at 3:39 PM, Chris Marrin <cmar...@apple.com> wrote: >>>> >>>> On Aug 31, 2010, at 3:25 PM, Maciej Stachowiak wrote: >>>> >>>>> >>>>> On Aug 31, 2010, at 2:06 PM, Chris Marrin wrote: >>>>> >>>>>> >>>>>> On Aug 31, 2010, at 11:48 AM, Kenneth Russell wrote: >>>>>> >>>>>>> On Tue, Aug 31, 2010 at 11:05 AM, David Hyatt <hy...@apple.com> wrote: >>>>>>>> On Aug 31, 2010, at 10:36 AM, Chris Marrin wrote: >>>>>>>> >>>>>>>>> Or should we get rid of Vector3, added the functionality it needs to >>>>>>>>> FloatPoint3D and use that? Ken Russell already has plans to do add >>>>>>>>> the functions to FloatPoint3D, so I would vote for that. >>>>>>>> >>>>>>>> I would vote for this. I don't think the geometry classes should move >>>>>>>> to wtf. >>>>>>> >>>>>>> I'd like to unify the math, geometry, and linear algebra classes that >>>>>>> are scattered around the WebKit tree -- for example, FloatPoint, >>>>>>> FloatPoint3D, FloatRect, FloatSize, the classes under >>>>>>> WebCore/platform/graphics/transforms/, these Complex and Vector3 >>>>>>> types, ... -- under a directory like WebCore/math, remove duplicate >>>>>>> functionality, and provide a cohesive set of interfaces that can be >>>>>>> easily used by other modules like graphics and audio. >>>>>> >>>>>> It would be nice if we could do this unification and then later on we >>>>>> can enhance it so the classes play nice together. For instance, >>>>>> TransformationMatrix deals with many, but not all of the other geometric >>>>>> classes. You can't cast between FloatPoint and FloatPoint3D, etc. Maybe >>>>>> we could also use this opportunity to change TransformationMatrix to >>>>>> Matrix. The current name is such a mouthful. And we might also want to >>>>>> think about changing FloatPoint3D to FloatPoint3. That would make it >>>>>> more natural if and when we want to add a FloatPoint4. We should also >>>>>> change AffineTransform to AffineMatrix so it matches Matrix. >>>>> >>>>> Mathematically, you can have an affine transform, or a matrix that >>>>> represents an affine transform. And there's such a thing as an affine >>>>> space (in fact IntPoint and IntSize form an affine space). But there's no >>>>> such thing as an affine matrix. >>>> >>>> Sure there is. It's a matrix that performs affine transformations. >>>> Mathematically it's represented as a 3x3 matrix, but like others, we just >>>> represent it as a linear transformation matrix (2x2) plus a 2D translation >>>> value. I think the name AffineMatrix is descriptive because, unlike a >>>> general 3x3 matrix, our truncated representation can only handle affine >>>> transformations. >>> >>> Chris, based on the precision of Maciej's reply, I suspect you do not >>> want to get into a semantic argument here... :) >>> >>> http://www.google.com/search?q=affine+matrix >> >> Oh, Ken, I'll argue about anything, you know that :-) >> >> 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. -Ken _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev