# [SVGMobile12] 16.2.6 Paced animation and complex types

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Thu, 10 Aug 2006 16:47:20 +0200

Message-Id: <200608101647.20253.Dr.O.Hoffmann@gmx.de>
```
Hello,

this is related to
http://lists.w3.org/Archives/Public/www-svg/2006Jun/0083.html
http://lists.w3.org/Archives/Public/www-svg/2006Jun/0085.html
http://lists.w3.org/Archives/Public/www-svg/2006Jun/0087.html
http://lists.w3.org/Archives/Public/www-svg/2006Jun/0089.html
it was desired to propose some better wording for the table.
The table in 16.2.6 is not yet changed in the new working draft from
21 July 2006 and I have some better ideas about this issue after
several experiments and calculations.
Reading SMIL2.1 about paced animation carefully, I noticed, that
there are several further corrections desirable to get the
table consistent with the meaning of a paced animation
as described by SMIL2.0/2.1.

SMIL notes about calcMode="paced" in
SMIL2.1: 3.5.2 Specifying the simple animation function f(t):

"
Defines interpolation to produce an even pace of change across the
animation. This is only supported for values that define a linear
numeric range, and for which some notion of "distance" between
points can be calculated (e.g. position, width, height, etc.).
"
And more:
"
For paced animations, the values are spaced so that a uniform
rate of change is obtained.
"

The main point about this is not to define ANY distance between
points to define ANY animation as paced, the main point is to get a
paced or uniform change across the animation. In other words this
means, the absolute value of velocity of the animation in the related
space is constant, or as a formular with p as a point of the animated
object or a value in an n-dimensional space and t the time: abs(dp/dt)
is constant.
And there is no need to define ANY distance, if there is no useful
distance or if some notion of "distance" to get a paced animation is
too complex. It is very simple just to say in the specification that for
the related attributes calcMode paced or some notion of "distance"
is not defined.
This is consistent with SMIL. Formulars leading to a not paced
animation are not consistent with the SMIL description and the
meaning of a paced animation.

Therefore the formulars for the following value types in the table of
16.2.6 are ok: angle, integer, length, coordinate, color (there are
other useful possibilities, but the current is consistent, except that is
not directly mentioned, what something like 'colorA.getRed()' means,
but it is understandable), transform translate, transform skewX,
transform skewY.
For the other types the formulars are in general wrong, or need for
'transform scale' further clarification. It is ok, how single distances are
calculated, but the averaging does not lead to a paced animation
anymore. And often not even a sample of distances will be
enough to provide a paced animation.
We will see it with some simple examples.

1. list of length
Lets take as a simple example an animation of the stroke-dasharray
attribute using the following:

values="1,1; 2,1; 2,2"

With the formular we come to the result, that a paced animation in this
special case has the same visual effect as calcMode="linear" with or even
without keyTimes="0; 0.5; 1".
The animated feature is the stroke-dasharray pattern, main structure
features are the borders between dashes and gaps. A paced animation
of the pattern with a uniform rate of change means the same visual effect
as calcMode="linear" with values="1,1; 2,2" which is a completely other
visual effect as described by the formular, therefore the formular does not
fit to a paced animation. In general there are n distances (maybe more)
needed for a stroke-dasharray list with n entries, not just one.
It is possible to implement this, but maybe it is too hard to claim this from
implementors. The easiest way out of the problem is simply to write:
"No distance is defined for the type 'list of length' and therefore no paced
animation is defined for it, calcMode="paced" has to be ignored and
calcMode="linear" used instead."

2. list of points
Lets take as a simple example an animation of the points attribute of a
polyline using the following:

values="0,0 0,1; 0,0 1,1; 1,0 1,1"

Again the formular of the table leads to a similar problem, the result has
the same visual effect as calcMode="linear" with or even without
keyTimes="0; 0.5; 1".
The animated feature is a simple line, a paced animation of the line with a
uniform rate of change means the same visual effect as calcMode="linear"
with values="0,0 0,1; 1,0 1,1" which is a completely other visual effect as
described by the formular, therefore the formular does not fit to a paced
animation.
Until nobody gives a prove, that n distances are enough to define the
paced animation of a complex geometric structure as a polyline or a
polygon, this leads to the same conclusion as for path data in the
following point.

3. path (data ?)

As already explained in a previous email, the formular leads already to funny
or
undefined results, if path data does not contain any control points. For
example
values="M0,0 L0,1; M0,0 L1,1; M1,0 L1,1".
This animation contains only points and not one control point as defined in
the path chapter of the specification .
Therefore all distances are either undefined or 0 (what is not consistent with
some notion of "distance").
It is undefined, which visual effect results from this - a jump from the first
to the last value at the begin or the end of the simple duration?

If we use, what I already proposed in a previous email, instead of just
'control points' 'points or control points' we get the same result as in 2.
for the
polyline calcMode="linear" with or even without keyTimes="0; 0.5; 1",
unfortunately again not a paced animation. Indeed a 'distance' is defined,
but this is not related to a uniform rate of change. But we have to note, that
the values do not only consist of numbers or points, there are commands too.
Both commands and numbers represent only the complete path, to
be paced animated. The animations has to be paced for the complete
path, not just for some points or control points.
Therefore the situation gets even more complex. To get a paced animation
from one path to another is not impossible, but non trivial cases require
a specification of the parametrisation of a path. For example define the
parametrisation as the fraction of the pathLength along the path for a
currect point of the path, lets call it s, then lets call the i-th path
p(i,s).
Something like a notion of "distance" is a point-to-point-distance-function
dependent on s, this is for example d(i,s) = dist(p(i,s)-p(i+1,s)),
Where dist means the euclidian distance between the two points on the
two paths i and i+1 at the position s. It is not impossible to animate
such things, but I think, this is far away from the things, implementors want
to do. Would be nice and useful to have it - but we cannot have everything.
It is maybe similar complex as the animation between paths containing a
different structure of commands, useful and possible too with a
parametrisation
as mentioned above, but excluded already for good reasons in the
specification.
Therefore again the conclusion is for 'path data' and 'list of points' the
same as for  'list of length':
"No distance is defined for this type and therefore no paced animation is
defined for it, calcMode="paced" has to be ignored and calcMode="linear"
used instead."

4. transform rotate

This was already explained in a previous email, but not only that the
formular mixes up different dimensions and the fact that it is not scalable
anymore. This means in other words a rotation angle and two translation
coordinates have not a common metric space to define something like a
distance. As in the previous example the averaging fails the feature to
perform an uniform rate of change.
If as proposed two distances are used, I think, it is a paced animation in
the related spaces of translation and rotation separately. If just the
distance only from rotation is used, of course the translation is not paced,
but it is a paced animation if the translational part remains constant
(what is often the case in practical applications).
The alternative is again to specify no distance and therefore no paced
animation as in the previous sections.

5. transform scale

Here the changed concept is a little bit surprising.
While for the 3-dimensional color type something like
an euclidian distance in the colour-space is used, for the
scaling-space a different kind of distance is used
(multiplied by 2 sometimes called City- or Manhattan-distance).
Why the euclidian distance is not used? Or does the
change indicate, that the working group does not believe
in a 2-dimensional  scaling-space and tries of use an average?
As we already found out in the previous sections, averaging
leads not to a paced animation. Therefore here it is a matter
of taste, what a distance in the 2-dimensional scaling-space
means and it is a matter of the question, if the working group
believes in a  2-dimensional  scaling-space to be able to define
a useful distance in this space or if it believes in 2 independent
parameters. In the last case again two distances have to be
defined, leading to similar conclusions as for 'transform rotate'
or 'list of length'.

To conclude: Several formulars in the table are consistent with a
paced animation of the related types.
But some formulars in the table do not fit to the meaning of a paced
animation. But I think for this types it is not very important for
authors to have the possibility of a paced animation. It is better not
to specify animations as paced in ANY way and situation, if the
correct way (constistent with the meaning of a paced animation as
described in SMIL) is too complex, not known or even impossible
now. It is much more useful simply to say:
'No, this is not defined by intention.'

Best wishes
```
Received on Thursday, 10 August 2006 14:46:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:09 UTC