Re: SVG animateMotion specification clarification request

Olaf,

Yes, a bug. A long standing bug. ASV, Opera, FF4 and until recently, 
Webkit all implement this concept incorrectly.  The test suite (author) 
interprets it differently.  Perhaps the implementations are victims of 
the test suite?  Until Shane brought it to our attention, it hasn't been 
an issue.

I understand and agree with what you are saying - that the 
translation/rotation effect of animateMotion can not be consistently 
applied in between the underlying transform and other animateTransforms. 
  As much as I want it to work, it just doesn't fit.

Having animateMotion become part of the sandwich as you described could 
work.  I think that approach could add some confusion in complex 
animations but possibly no more than exists with animateTransform 
already.  I'm not sure it would be a problem for real world use cases, 
but I need to think more on that.

Another possibility is to premultiply the animateMotion effect - the 
path would then be defined in the parent coordinate space and not be 
affected by animateTransform.

I have no desire to corrupt the recommendation for the sake of fixing 
viewer bugs.  I do question how useful it is to animate the coordinate 
space of the motion path.


Looks like I may have some work to do to generate animations which 
conform to the spec.  On the plus side, the nesting which will be 
required means the new structure will work on the existing viewers.

Ken


Dr. Olaf Hoffmann wrote:
 > 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 20:08:06 UTC