Re: [Matrix] restating the goals?

On Thu, Mar 21, 2013 at 3:13 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Thu, Mar 21, 2013 at 3:01 PM, Dean Jackson <dino@apple.com> wrote:
> > Since the discussion has exploded to the point of being difficult to
> follow, with a number of people expressing strong objections to the
> proposal, I was wondering if it was worth stopping to decide if we can at
> least agree on the goals at a very high level.
> >
> > - Have some way to express a CSS (and SVG) transformation in JS that is
> better than the current solution of the CSS OM (uses long strings which
> need to be parsed in/out)
> >
> > - Do this in a way that doesn't break existing content (i.e. we can't
> change SVGMatrix, as much as we'd love to). This could mean a completely
> new API.
> >
> > - Help developers do the common things with simple, performant code.
> >
> > When I look at the above, I wonder if the problem comes from this
> assuming to be a Matrix API. It's really just an API for the native
> transformations that exist in the platform. Is it possible to think of it
> as a way to accomplish a transformation in JS that corresponds to what
> you'd typically use CSS for? e.g.
> >
> > element.style.transform = "translate3d(10px, 10px, 10px) rotateY(1rad)
> scale(2)";
> >
> > Should be able to be expressed something like this:
> >
> > var t = new Transform();
> > t.translate3d(10, 10, 10);
> > t.rotateY(1);
> > t.scale(2);
> > element.transformMatrix = t;
>
> I've so far been treating it exactly like this, but thank you for the
> refocusing, as I suspect a good part of the conversation was spawned
> by confusion over this point.
>
> > This would mean all the inverse/decompose/etc stuff gets dropped, which
> is fine with me. Again, the target is our transformation implementation,
> not a general matrix library. If the transformMatrix property, or whatever
> it is called, accepted a Float32Array, then people could use whatever
> matrix library they want.
>
> I think it's reasonable to push *just a little* bit further, so that
> people can use this class, in JS, to accomplish the same things as CSS
> transforms in an easy way (rather than being focused purely on
> literally manipulating CSS transforms).  As such, inverting is still
> useful (but there's definitely no reason to throw), and decomposition
> *might* be (given that CSS transforms transition as a decomposed
> matrix when they mismatch too hard, so if you want similar behavior in
> JS, exposing this could be useful).
>

I think matrix interpolation should also be in the API and use the same
algorithm that the browser is using.
The reason for having it is that it will automatically adapth javascript
driven animations in case we find a bug or update the algorithm.


>
> I totally agree with anything that accepts a Matrix also accepting a
> properly-sized TypedArray.


Agreed. (Altough I would like to get input from VM people; from what I've
learned about V8's optimizations, they only generate native code for
objects)