Re: SVG animateMotion specification clarification request

Ken Stacey:

> > Something like RT * MP * MR * AS does not fit to SMIL/SVG at all,
> > this would be very odd -
>
> Odd as it may seem, this is how ASV and Opera have appeared to implement
> it.

This is clearly a bug, because for all versions of SVG it is required to 
postmultiply an additive animateTransform to the underlying value
(this can be another animateTransform with lower priority or in this
case simply the value noted in the transform attribute).
To change this, requires to change the complete concept of additive
animateTransform.
Well, animateTransform has already some other problems like that of
to-animations, but this should be no reason to corrupt the concept just
because in some viewers there is a bug, if there appears an additional
animateMotion, that has - up to now - nothing to do with additive 
animateTransform oder animateTransform at all ;o)

>
> > or this means basically to define that animateMotion is not
> > supplemental to animateTransform, more an alternative way to provide
> > an animation of the transform attribute with only translation and
> > rotation - but then the order of begin times and the order within the
> > source code of animateMotion and animateTransform becomes important
> > as well - including the conplication to indicate them to be additive,
> > if itis required that the later one does not replace the earlier
> > one.
>
> I think all it means is that animateTransform is supplemental to
> animateMotion.

Well this means either 
RT *  AS * MP * MR
or
MP * MR * RT *  AS
or 
MR * MP * RT *  AS
for the given example.

>
> I agree that giving equal status to animateMotion and animateTransform
> does introduce some complications.

This would happen for 

RT * MP * MR * AS

for example, if there are several additive animateTransform elements with
several begin and end times - therefore the underlying value changes all
the time, sometimes it is the RT, sometimes the current value of another
animateTransform or a combination of that. 
Finally there is not just one animation effect for the related attribute,
it is some mess of changes of something, nobody really has a name for ;o)
This could be only avoided by indicating, that animateMotion is not
supplemental, but only contributing to this sandwich model of transformations.

Here as typically it is much better simply to fix the bug in the viewers
instead of corrupting a well considered concept in the recommendation ;o)
Fixing the bug simply solves the problem. Corrupting the recommendation
mainly results in something we can observe in the HTML5 draft - a lot of
complex and hardly to understand rules based on bugs of viewers, not
really meaningful or simple to keep in mind for authors and implementors.

Olaf

Received on Monday, 31 January 2011 15:31:17 UTC