W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Re: Proposal: transformation matrix interface

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 13 Mar 2013 19:24:32 -0700
Message-ID: <CAGN7qDB4TeQ0OmSdpCo6=Nb11tC+HVZvUwmw35v6t0y5bJRswQ@mail.gmail.com>
To: David Sheets <kosmo.zb@gmail.com>
Cc: Dirk Schulze <dschulze@adobe.com>, "www-svg@w3.org list" <www-svg@w3.org>, www-style list <www-style@w3.org>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>
On Wed, Mar 13, 2013 at 4:21 PM, David Sheets <kosmo.zb@gmail.com> wrote:

> On Sat, Mar 9, 2013 at 5:50 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> > On Feb 14, 2013, at 3:21 PM, David Sheets <kosmo.zb@gmail.com> wrote:
> >> 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.
> >
> > There is a DOMException interface to generate DOMExceptions. You can
> prototype Matrix with your own methods and attributes that can throw your
> generated exceptions. Is that sufficient for you?
>
> Does that provide identical semantics? Has something changed since
> Marcos' SO answer
> <
> http://stackoverflow.com/questions/5136727/manually-artificially-throwing-a-domexception-with-javascript#answer-9856490
> >
> and the thread on public-script-coord
> <
> http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0458.html
> >?
>
> Is there some way to make instanceof behave identically? Or do Matrix
> users need to wrap a native Matrix to poke for exceptions? What
> happens when a script in a JS environment without DOM (e.g. node.js)
> wants to use a Matrix?
>
> >> 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.
> >
> > At the moment Matrix follows CSS3 Transforms and the implementation
> behavior of browsers. The definition seems bogus, since we just have one
> quaternion with 4 arguments, not two. I will correct the specification
> text. In the meantime, can you go into more details how you suggest this
> operation should look like?
>
> I think the provided pseudocode implements what I am proposing the
> prose describe.


Are you saying that the pseudo code is what you want and that it's the
prose that is wrong?


> Specifically, I believe that the prose should indicate
> that a single quaternion is returned which has a non-zero scalar part
> and L_2 magnitude of 1 ("unit quaternion"). It might also mention that
> this implies that the returned quaternion represents the geodesic
> (shortest path) for interpolators. To produce the complementary arc,
> the quaternion's elements simply need scaling by -1. This requirement
> is quite cheap for implementors, nicely uniform for users, and a good
> invariant.
>

Is this your proposal for the updated prose?


>
> Thanks for your work.
>
> Hope this helps,
>
> David
>
>
>
Received on Thursday, 14 March 2013 02:25:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:07 GMT