[webkit-dev] Complex and Vector3 classes in WTF?

[Kenneth Russell]

On Tue, Aug 31, 2010 at 4:22 PM, Maciej Stachowiak <mjs at 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 <cmarrin at 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 <hyatt at 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