Re: [css3-transforms] ... paced animation

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.


Olaf

Received on Monday, 4 June 2012 12:47:51 UTC