[SVGMobile12] 16.2.6 Paced animation and complex types

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