- From: Chris Marrin <cmarrin@apple.com>
- Date: Fri, 27 Mar 2009 10:54:47 -0700
- To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
- Cc: www-style@w3.org
On Mar 27, 2009, at 3:14 AM, Dr. Olaf Hoffmann wrote: > Dean Jackson: >> I'm afraid I disagree. Our main goal is to make the most common case >> both simple to author and look good. > > Matrix animation with composition by the author and some decomposition > by the viewer will not be a common case, I guess. Most authors will > not > be familiar with matrix calculations anyway and for the others it is > still > more convenient simply to write down the complete set of intended > transformations and let the viewer do the job of matrix calculations. > >> The way we have specified >> transform animations meets this (I believe). >> >> A secondary goal is to give authors complete control. The current >> specification also meets this. An author can avoid decomposition if >> they want to (it requires more work, but if they are *that* >> determined >> to control every aspect of their animation then they probably have it >> all worked out already). > > Well, then explain a simple approach for authors to specify an > animation (direct interpolation) between matrix A and matrix B > with an accuracy better than one device pixel. > If you can do it with the current draft, then I'm almost convinced, > that at least nothing is missing, even if other things are available > twice. I'm not sure what you mean by "better than one device pixel". If you have a matrix with just translation values, for instance, then matrix animation would animate from one to the other just as accurately as animating the components directly. Same for scale and rotation. It's when you combine everything that things get interesting. And in that case, we believe the author's intent is to go from one "pose" to another in the most natural way. For instance, if one pose is the object at a scale of 0.5 with a slight cant up and to the left and the other pose is the object at a scale of 1 with a slight cant up and to the right, then we believe the author's intent is to smoothly scale up the object while at the same time pivoting from left to right. And that's what you would get with matrix animation. For instance: from: -webkit-transform: scale(0.5) rotateX(15deg) rotateY(-30deg); to: -webkit-transform: rotateX(15deg) rotateY(30deg); This can't do a component by component animation because the functions don't match. But a decomposed matrix animation would give you the desired result. And linear interpolation of the matrix values would give add a implicit converse scale that would interfere visibly with the smoothness of the scale from 0.5 to 1. Do you have any practical use cases where a linear interpolation would do something reasonable (much less preferable) where a decomposed matrix would not? > > > And it does not solve the possible mathematical problem with the > inverse, just to believe, that it works ;o) > I had already similar discussions to fix such believes for > constrained transformations in SVGT1.2. A non-invertible matrix would result in nothing rendered, so what practical use do you have for them? Again practical examples would be helpful. ----- ~Chris cmarrin@apple.com
Received on Friday, 27 March 2009 17:55:29 UTC