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

Date: Mon, 4 Jun 2012 14:20:33 +0200

To: public-fx@w3.org

Message-Id: <201206041420.33729.Dr.O.Hoffmann@gmx.de>

Date: Mon, 4 Jun 2012 14:20:33 +0200

To: public-fx@w3.org

Message-Id: <201206041420.33729.Dr.O.Hoffmann@gmx.de>

Dirk Schulze: ... > > > > If you have for example two translation values, a meaningful > > distance function is the Euclidian distance, nothing else. > > For scale the same. > > But if you animate from a rotate value to a translation value > > with animate for example, of course no paced behaviour is > > possible, even worse with distortion due to skew or 3D transforms. > > animateTransform has always a defined type of transformation, > > therefore for such a type sometimes one can define paced > > behaviour. > > For the animate type typically not - or one has to restrict > > this on cases, where the type does not change for the > > complete values list, this means, that there is no decomposition > > for the complete active duration. And of course, if each value > > consists of more than one type, even if this is the same list > > for each value, there will be typically no paced behaviour anymore. > > The SVG WG agreed to let paced animation undefined for CSS3 Transforms. The > ED already does so [1]. At the moment I am unsure what would be the best > definition for paced animations. On the one hand I would like to have at > least the same possibly for paced interpolations like on animateTransform, > on the other hand I am unsure if the spec should explicitly deny specific > transform-list animations to be paced. Or better how should a > transform-list look like to allow paced animations. Since CSS3 Transforms > interpolates each function pair separately as long as the transforms follow > the third (and second) rule of [2], I don't see a reason not to allow paced > animations for these kind of interpolation. Like discussed above, the > implementation must verify the complete animation steps to verify that the > third rule is always true. But then again, like you said in another post, > even rotate with three arguments is not allowed together with paced > animations. This is something that should be discussed in a new thread. > I think, the core use case for paced animated transformations is translation with the Euclidian distance. This should be defined at least for 3D translations with animateTransform, because here we can be sure, that we have only one type. For these mixed transform function list the situation is hopeless. But undefined is in general not a good idea, therefore it should be noted, that no meaningful distance function can be defined for such mixed values and therefore it should be used the default fallback (linear). Because this CSS transform approach requires to interpolate only between to consecutive values, but the paced calcMode requires to determine the distance along the complete list - and you cannot add for example numbers, lengths, angles, vectors, such an approach excludes paced behaviour. In general, if you want to define some distance for a new type for animateTransform, that is more complex as a scalar value, first you have to explain, what it means to have a paced changes - this means roughly, that the absolute value of the 'velocity' of value (absolute value of the first time derivate of the value) of an entity remains constant. You can interprete this entity geometrically as for translation and you may get a distance function, like the Euclidian distance for translations, this results for a 3D translation into a motion with a constant absolute value of the velocity. For rotation around a fixed rotation center of around a fixed vector, the absolute value of the angular velocity has to remain constant. For a physical object, if the vector moves, this means a force on the object, indicated by precession, nutation. Often the direction of the vector may rotate paced, but it is possible as well, that the vectors is only moved perpendicular to the rotation axis, in this case this rotation can be still paced. Therefore still the motion of the vector may remain paced and the roation around the vector, but this means, you need one distance function for the vector and an independent for the rotation. This would result in an independent timing for the motion of the vector and the rotation, this means effectively two keyTimes lists, but this is not possible currently and I think, within the discussion for SVG tiny 1.2 about this issue there was a decision to avoid such an extension of SMIL animation. Therefore wrong paragraphs in the recommendation and examples in the test suite were fixed. For other types like the scaling, I think, there are no really important use cases, netherless it is relatively simple to define paced behaviour. For this you use the 'abstraction' of a motion in the scaling space. With this soon you will get the Euclidian distance in the scaling space as result. To resume: Paced behaviour for translation is of some importance, therefore it can be useful for some authors to have it. For some other types one can find the correct and meaningful distance function, but my assumption is, that there are no real use cases for them. For other types there are no obvious distance functions available. If you find one, it can be expected, that you can explain in detail, how this is related to a paced change - with which geometrical meaning or in which space. OlafReceived on Monday, 4 June 2012 12:47:51 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Monday, 4 June 2012 12:47:52 GMT
*