Re: animateMotion keyTimes question

Renata Hodovan:

...

><animateMotion calcMode="linear" keyPoints="0.8" keyTimes="0" by="3"/>

>Digging the implementation I realized that having only one keyPoint and 
>one keyTime is considered as invalid in almost every cases except the 
>from/to/by animations. Is this just an implementation mistake or is 
>there any reason behind it?

Typically it causes no invalid situation to have only one value,
it causes simply just no interpolation, see below.

Note that you can have a similar situation as well with the values attribute
and other animation elements, for example:
<animateColor attributeName="fill" values="#000" keyTimes="0" 
calcMode="linear" />
This is comparable to a set animation (because you cannot have 
a set animation for animateTransform or animateMotion, you need to
use such notation to get the equivalent effect ...)

Another note:
by="3" is equivalent to values="0;3" additive="sum", therefore
without the keyPoints attribute it would have two values, not one.
But to-animations are another type of animation, there is no equivalence
to any kind of values-animation.
For a to-animateMotion with a keyPoints attribute one has to explore
pretty carefully, what is correct behaviour, basically to-animations
are always different, what makes them pretty interesting for authors,
if it would be implemented correctly, what is currently not the case for
any viewer I know - they all fail at some point unfortunately...


Back to the examples:
On the one hand it is noted about keyTimes:
'For linear and spline animation, the first time value in the list must be 0, 
and the last time value in the list must be 1'.
And 
'For discrete animation, the first time value in the list must be 0.'

Because keyPoints and keyTimes need to have the same number
of items, those examples seem to cause a problem or inconsistence.

However it is noted for  calcMode:
'Specifies the interpolation mode for the animation... The default mode 
is 'linear', however if the attribute does not support linear interpolation 
(e.g. for strings), the ‘calcMode’ attribute is ignored and discrete 
interpolation is used.'

Obviously, for one values item or keyPoints item there cannot be interpolation
at all, therefore this rule applies and calcMode discrete applies
automatically, whatever the noted attribute value is 
(this can apply for some other circumstances as well,
for example if a values list for fill or stroke contains non interpolable 
values like 'none' or 'url(#id)',  what is implemented often wrong, however).

Therefore effectively we neither get the default paced animateMotion for
the example nor the noted linear animation, but a discrete animation
and the conflict is solved for this issue.

The bigger problem with your example is related to this definition of
animateMotion:
"For ‘animateMotion’, the specified values for ‘from’, ‘by’, ‘to’ and ‘values’ 
consists of x, y coordinate pairs, with a single comma and/or white space 
separating the x coordinate from the y coordinate."

In the given example we find only one number as value. 
For such an invalid value, I think, there is no specific rule in SVG, 
therefore the rule from SMIL applies: The animation has no effect 
(it can be used for synchronisation but has no direct animation effect
itself).


Olaf

Received on Wednesday, 13 August 2014 15:28:54 UTC