Re: SVG animateMotion specification clarification request

On Tue, Feb 1, 2011 at 7:07 AM, Ken Stacey <ken@svgmaker.com> wrote:
> 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.

It's worth noting that WebKit had a different (but also incorrect)
implementation - while ASV and Opera do:
RT * (MP * MR) * AS

Until recently WebKit was doing:
(MP * MR) * RT * AS

In accordance with the current version of the specification, WebKit
trunk now does:
RT * AS * (MR * MR)

It's precisely the inconsistency between implementations that led me
to bring this matter up in the first place.

Cheers,
    -Shane

> 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 23:05:21 UTC