Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Sep 1, 2010, at 1:48 PM, Simon Fraser wrote: > On Sep 1, 2010, at 1:04 PM, Chris Marrin wrote: > >> On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote: >> >>> On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote: >>> 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. >>> >>> Transform sounds ok to me, actually, even though it is a little broad. >> >> Filed as https://bugs.webkit.org/show_bug.cgi?id=45051. I also opened >> https://bugs.webkit.org/show_bug.cgi?id=45052 for the work to change >> Transform back to floats. I'm not sure we've fully committed to do this, but >> I wanted it recorded in the bug list. We can invalidate it if we don't end >> up doing it. > > SVG already has SVGTransform, the interface for one of the component > transformations within an SVGTransformList, which has an SVGMatrix property, > which represents the matrix. > > I think Transform is going to get too easily confused with existing transform > terminology related to CSS and SVG transforms, and maybe XSLT too. It's true that we have many Transform concepts. But this Transform class is at the bottom of the CSS and SVG transformation logic, so doesn't it make sense that it is the simplest name? - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Sep 1, 2010, at 1:48 PM, Simon Fraser wrote: > On Sep 1, 2010, at 1:04 PM, Chris Marrin wrote: > >> On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote: >> >>> On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote: >>> 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. >>> >>> Transform sounds ok to me, actually, even though it is a little broad. >> >> Filed as https://bugs.webkit.org/show_bug.cgi?id=45051. I also opened >> https://bugs.webkit.org/show_bug.cgi?id=45052 for the work to change >> Transform back to floats. I'm not sure we've fully committed to do this, but >> I wanted it recorded in the bug list. We can invalidate it if we don't end >> up doing it. > > SVG already has SVGTransform, the interface for one of the component > transformations within an SVGTransformList, which has an SVGMatrix property, > which represents the matrix. > > I think Transform is going to get too easily confused with existing transform > terminology related to CSS and SVG transforms, and maybe XSLT too. Alternative? - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Sep 1, 2010, at 1:04 PM, Chris Marrin wrote: > On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote: > >> On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote: >> >>> >>> 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. >> >> Transform sounds ok to me, actually, even though it is a little broad. > > Filed as https://bugs.webkit.org/show_bug.cgi?id=45051. I also opened > https://bugs.webkit.org/show_bug.cgi?id=45052 for the work to change > Transform back to floats. I'm not sure we've fully committed to do this, but > I wanted it recorded in the bug list. We can invalidate it if we don't end up > doing it. SVG already has SVGTransform, the interface for one of the component transformations within an SVGTransformList, which has an SVGMatrix property, which represents the matrix. I think Transform is going to get too easily confused with existing transform terminology related to CSS and SVG transforms, and maybe XSLT too. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote: > > On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote: > >> >> 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. > > Transform sounds ok to me, actually, even though it is a little broad. Filed as https://bugs.webkit.org/show_bug.cgi?id=45051. I also opened https://bugs.webkit.org/show_bug.cgi?id=45052 for the work to change Transform back to floats. I'm not sure we've fully committed to do this, but I wanted it recorded in the bug list. We can invalidate it if we don't end up doing it. - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote: > > 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. Transform sounds ok to me, actually, even though it is a little broad. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Wed, Sep 1, 2010 at 11:43 AM, Chris Marrin wrote: > > On Aug 31, 2010, at 6:59 PM, Kenneth Russell wrote: > >> On Tue, Aug 31, 2010 at 6:42 PM, Maciej Stachowiak 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Aug 31, 2010, at 6:59 PM, Kenneth Russell wrote: > On Tue, Aug 31, 2010 at 6:42 PM, Maciej Stachowiak 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. - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Tue, Aug 31, 2010 at 6:42 PM, Maciej Stachowiak 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 API. -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
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. > > 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
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 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)? - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Tue, Aug 31, 2010 at 4:22 PM, Maciej Stachowiak 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 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 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
Re: [webkit-dev] Complex and Vector3 classes in WTF?
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 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 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. 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Aug 31, 2010, at 3:43 PM, Kenneth Russell wrote: > On Tue, Aug 31, 2010 at 3:39 PM, Chris Marrin 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 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. - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Tue, Aug 31, 2010 at 3:39 PM, Chris Marrin 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 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 -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
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 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 cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
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 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Aug 31, 2010, at 11:48 AM, Kenneth Russell wrote: > 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 All of the classes you mentioned (with the exception of Complex and Vector3) are in the WebCore/platform/graphics tree. That seems pretty consolidated to me, though clearly there are a lot of other kinds of classes in that tree. It's not clear that WebCore/math is better (though I'm not opposed to it). -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Aug 31, 2010, at 11:48 AM, Kenneth Russell wrote: > On Tue, Aug 31, 2010 at 11:05 AM, David Hyatt 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. But I think it should stay in Platform. That's where most of them are already and it allows us to make platform specific versions as needed. For instance, we could add an SSE implementation of Matrix that way. Then this gets us back to an earlier issue. Currently TransformationMatrix uses doubles and the rest use floats. Should we change it back to using floats everywhere? I've opened a bug for just the reorg part: https://bugs.webkit.org/show_bug.cgi?id=44983 Please add any classes scattered around I might have missed. - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
On Tue, Aug 31, 2010 at 11:05 AM, David Hyatt 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. -Ken > > dave > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Complex and Vector3 classes in WTF?
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. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Complex and Vector3 classes in WTF?
I just noticed these classes, added 7 months ago as part of Chris Rogers' audio work. I think it's a mistake to have these in WTF for a few reasons: 1) Complex is just std::complex with a single added function, complexFromMagnitudePhase(), which seems pretty audio specific, so it should go with the audio code 2) Vector3 has a name very similar to Vector, but with completely different functionality. I actually opened wtf/Vector.h thinking I was going to see a 2D Vector class (because I was in that mindset), then I remembered the _other_ meaning of Vector! So I think it's pretty confusing. 3) Vector3 goes along with other classes, like 2D point, matrices and maybe even lines, planes and other geometry related things. Right now we have FloatPoint2D, FloatPoint3D and TransformationMatrix in WebCore/platform/graphics. These should all be together. I think we should move Complex.h over to live with the rest of the Chris' audio code. Vector3 is a more complex ( ! ) issue. Should we move all the geometry related classes to WTF? If we did I think that should include all the Rect and Box classes as well. 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. There's one other problem. Vector3 uses doubles, while FloatPoint3D uses floats. Chris, do you need doubles for your use, or would floats suffice? What do others think? - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
