Re: [css3-2d-transforms] matrix animation

Olaf,

On 26/03/2009, at 12:49 AM, Dr. Olaf Hoffmann wrote:

> I think, it is not a good idea, that a matrix is decomposed in an  
> (arbitrary)
> set of other transformations for animation purposes, because:
> 1. Authors should have the choice. If they need a (non) arbitrary  
> set of
> other transformations, they can simply write down these sets instead  
> of a
> matrix. If they need an animation between two matrices, it is the  
> simplest
> idea to write down exactly two matrices.
> 2. Interpolation between the matrix components within the animation
> results in different effects than with a decomposition and animation  
> of
> each decomposition transformation. Matrix animation can be interesting
> for authors too, but is currently not available, if the matrix is  
> decomposed
> before the animation interpolation takes place.
> 3. The decomposition is almost opaque for the author, the author has
> no control over this. And it cannot be expected, that authors have  
> to learn
> c to understand, what happens. The separation in his own set of
> transformations including matrices without any manipulation ensures
> transparency and complete control for the author.
> 4. As far as I understand the source code referenced for the  
> decomposition,
> this can introduce unneccessary mathematical problems. I'm not a
> c-programmer, I use other programming languages, but as far as I  
> understand
> the code, it makes use of a matrix inversion do get the decomposition.
> Within the animation (especially if a given value is somehow  
> mirrored), there
> may appear matrices without an inverse, for them there is obviously no
> decomposition with this code.
> With skewing it is possible too to have infinite matrix elements, if a
> transform list is converted into a matrix and decomposed again, this  
> may
> result in an undefined matrix.
> 5. There is no real benefit for authors with this decomposition, I  
> think this
> is only introduced to simplify the life of implementors without any
> usecase not avialable without the decomposition, therefore there is no
> loss, if this is skipped.
>
> To resume, I suggest to skip the decomposition idea completely. This
> avoids mathematical problems and paternalism of authors.

We strongly disagree. We came to this approach for a few reasons:

1. It looks *MUCH* better. I suggest you try animating complex  
matrices without decomposition, especially in 3d, and see what  
happens. You'll notice that what should be a straight-forward  
animation looks like crap in most cases. This approach puts the  
author's needs first.

2. The choices are not arbitrary. Yes, there are lots of different  
ways to decompose a matrix, but this approach is widely implemented  
and documented. Unless you meant that it is arbitrarily triggered, but  
I think the spec is pretty clear that it happens only when you use  
matrix, matrix3d or the list of transform functions does not match. I  
would predict that in 99+% of cases the lists will match and the  
author has complete control.

3. It isn't opaque to the author - in fact, it's better than not  
decomposing the matrix. You would find it difficult to explain to the  
author what linear interpolation of matrix values actually means to  
their content, even though the concept is extremely simple.  
Furthermore, if authors want fine control over their animation then  
they will use multiple transform functions - I don't see a reason for  
an author to use a matrix unless they are forced to.

Lastly, decomposition is most definitely not "only introduced to  
simplify the life of implementors". Without decomposition this is  
trivial to implement. We added all this extra work because we're sure  
that authors would want it.

Dean

Received on Wednesday, 25 March 2009 19:45:49 UTC