From: Dean Jackson <dino@apple.com>

Date: Thu, 26 Mar 2009 06:45:05 +1100

Cc: www-style@w3.org

Message-Id: <102822C5-CAD1-491C-9547-B43AA0802462@apple.com>

To: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

Date: Thu, 26 Mar 2009 06:45:05 +1100

Cc: www-style@w3.org

Message-Id: <102822C5-CAD1-491C-9547-B43AA0802462@apple.com>

To: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

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. DeanReceived on Wednesday, 25 March 2009 19:45:49 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 16:27:58 UTC
*