Re: Proposal: transformation matrix interface

Hi Dirk,

This interface is really nice and a unified tensor algebra (even 1-
and 2-tensors only) for the web environment is a huge win, imho.

>From my cursory reading of your draft, I have the following comments:

1. Could a Float64Array constructor and toFloat64Array method be
added? This would provide applications the ability to transform
between Matrix objects and typed arrays without loss of precision.

2. Is a DOMException necessary for the error conditions? Are
DOMExceptions generateable by user code? I would like to be able to
provide user-space implementations of Matrix that internally leverage
invariants for better performance/behavior. For example, if I know
that I am only dealing with rotation matrices, I might use an
implementation of Matrix that internally uses only a quaternion
representation. Similarly, if I know that I am only going to use
special orthogonal transformations (no scale, no skew, det=1), I might
use a dual quaternion representation internally. It would be nice to
be able to pass these constructions into APIs that expect Matrix
objects without building a native Matrix first.

3. The rotate method does not appear to have enough parameters to
determine the rotation which it describes. In 2-d, there is only a
single plane of rotation. In 3-d, there are 3 planes of rotation.
Method 'rotate' specifies an origin in R^3 and an angle but does not
specify a plane of rotation. Have I missed something?

4. In DecomposedMatrix, "quaternions of type sequence<double> Is an
sequence of four double items representing the two quaternions for the
rotation of the matrix." In the pseudocode for the decomposition, I
only see a single quaternion generated. The other quaternion that
describes the rotation is simply the negation of this quaternion as H
double covers SO(3). I believe that the decomposition should always
return the quaternion that represents the shortest rotation which
corresponds to the quaternion with a positive scalar component
(quaternion[3]?). This matters when an API user wants to take the
logarithm of a quaternion and retrieve consistent bivector angles.

I hope these comments have been useful and this was the sort of
feedback you were seeking.

Thanks for all your work on these technologies. Getting this
standardized and deployed will really help the WWW compete.

Warm regards,

David

On Thu, Feb 14, 2013 at 2:29 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> Hi,
>
> The SVG specification[1] has various interfaces for transformations and matrices. One important interface is SVGMatrix which represents a 2D transformation matrix. With the support of CSS3 Transforms[2], the SVGMatrix interface needs to be replaced by a transformation matrix format that allows a 4x4 transformation matrix to represent 3D transformations and perspectives.
>
> The SVG WG believes that it should investigate into an interface 'Matrix' that is not limited to SVG, but can be used together with other specifications as well. Possible specifications that may would benefit of this interface are:
> * CSS Transforms (the next level),
> * CSSOM[3] to provide access to the matrix data,
> * HTML Canvas2d[4] which uses SVGMatrix to describe CTMs at the moment,
> * WebGL[5] for representing transformation matrices as well.
>
> The benefit of a common interface is the interoperability between specifications. CSS Transforms can share the transformation data with HTML Canvas or WebGL and vice versa. This allows a new level of interaction between different parts of the web platform. To avoid delays, the interface will be a separate specification with the goal to proceed very fast.
>
> Some details:
>
> * The Matrix interface provides read and write access to each element of the 4x4 transformation matrix: m11-m44
> * It is possible to just use a 2D subset of the 4x4 matrix with the elements a-f of a 3x2 matrix. Internally these attributes are just aliases to the corresponding elements on the 4x4 matrix.
> * The idea is to specify the most necessary attributes and methods for a first revision and extend the interface in future revisions as needed.
> * SVGMatrix must be an subset of Matrix. As such, Matrix supports all methods of SVGMatrix, partly extended for the 3D use cases.
> * Rotations are described in degree to be backward compatible to SVGMatrix.
>
> The SVG WG asked me to come up with a proposal and present it to the mailing lists. The drafted proposal is based on an email from Dean Jackson early 2012[6]. I worked together with Dean and the SVG WG to verify the initial proposal.
>
>
> You can find the drafted proposal on the mercurial directory of the FX TF: https://dvcs.w3.org/hg/FXTF/raw-file/tip/matrix/index.html
>
>
> I am happy about editorial feedback. Right now I would like to ask you for an initial, informal review of the proposal. Please send your thoughts and suggestions to the mailing list. If the WGs agree to continue with this proposal, we would need to figure out which WG is involved and who will be the editor of the possible specification.
>
> Greetings,
> Dirk
>
> [1] http://www.w3.org/TR/SVG/coords.html
> [2] http://dev.w3.org/csswg/css3-transforms/
> [3] http://dev.w3.org/csswg/cssom/
> [4] http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/
> [5] https://www.khronos.org/registry/webgl/specs/1.0/
> [6] http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0007.html

Received on Thursday, 14 February 2013 23:24:40 UTC