Re: SVG animateMotion specification clarification request

Hi mailing list members,

WebKit switched back to it's old behavior on animated transform multiplications and behaves like Firefox again. See description at the end of the mail.

I'd still recommend to rethink the content of the spec about supplemental transforms for animate motion or make it more clear how the calculation is done. In my opinion the first important step is that implementers agree to a certain concept. Otherwise web developers are forced to use nested group elements. And that would lead to large and confusing SVG contents.

I'd prefer to add animateMotion to the sandwich model (like others mentioned as well). Means all active animated transformations get applied to the CTM once after the other, depending on the order of the animation elements in the DOM. That would give the web author more control on how the animations get applied to the CTM. If the author needs to pre multiply any animated transform before to the local transforms [1] of an element, he/she has to nest the element in a group element and animate the group element.

animateMotion may consist of two transformations: the translation and the rotation. I believe that these transformations should not get separated (in the context of Shane Stephens examples: (MP * MR) or (MR * MP)). If we keep the supplemental transform, the motion transformations should get post multiplied to all local transforms and animated transforms. This mostly makes the decision easier for developers how to use animateMotion - in my opinion. Shane Stephens has more examples for this point.

Even so: If we get a consensus how to multiply all the transforms, we'll change the behavior on WebKit ASAP.

Greetings
Dirk

[1] With local transforms I mean transforms set by the 'transform' attribute: <rect transform="scale(2) ..." .../>


To the current behavior of WebKit nightly (and Firefox nightly):
==============================================

Example:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect x="500" y="0" width="100" height="100" fill="green" transform="translate(100,5) scale(0.5)">
   <animateMotion id="a1" path="M 20,0 C 20,50 100,50 100,0" rotate="auto" begin="0s" dur="5s"/>
   <animateTransform id="a2" attributeName="transform" type="translate" from="0 0" to="20,20" begin="0s" dur="5s" additive="sum"/>
   <animateMotion id="a3" path="M 20,0 C 20,25 100,25 100,0" rotate="autoRevert" begin="0s" dur="5s" additive="sum"/>
   <animateTransform id="a4" attributeName="transform" type="rotate" from="0" to="180" begin="0" dur="5s" additive="sum"/>
</rect>
</svg>

The example consists of the local transforms:
* translate(100,5) - LT1
* scale(0.5) - LT2

and four animated transforms:

1) animateMotion  #a1
path "M 20,0 C 20,50 100,50 100,0" - MP1
rotate auto - MR1

2) animateTransform #a2
translate: 0 0 to 20 20 - AT1

3) animateMotion #a3
path "M 20,0 C 20,25 100,25 100,0" - MP2
rotate autoRevert - MR2

4) animateTransform #a4
rotate: 0-180 - AT2

In general we multiply:

animated motion (MP * MR)   *   local transforms   *   animated transforms

For the example WebKit uses the following multiplication:

MP1 * MR1 * MP2 * MR2 * L1 * L2 * AT1 * AT2
(The combination of MP1 to MR2 is the supplemental transform)


Am 03.06.2011 um 12:12 schrieb Alex Danilo:

> Hi Dirk,
> 
> 
> 	I've tried to ignore this thread for a while for my sanity:-)
> 
> 	Anyway, there are about 5 Tiny viewers that are consistent with
> 30-t. We handle 24-t and 30-t OK.
> 
> 	It's been a good 5 years or so since I wrote that code, so it's
> a long distant memory, but trying to sort through the emails and look
> at the comments in our source I see this "In the case of animateMotion,
> it's applied before any transforms on the element itself" and the code
> seems to re-arrange it so that the animateMotion is applied to the
> CTM before the animateTransform(s) are. This doesn't sound consistent
> with the wording in the spec. which says that the animateMotion is
> supplemental (as Shane originally pointed out).
> 
> 	In my very vague recollection, to pass 24-t that was what was
> required - as if the motion is applied first, then any animateTransform
> so that the object can grow/skew, etc. independent of where it is moving.
> 
> 	If I get a chance I'll try to analyze this a bit better but
> from this quick look at it, the spec. is misleading since we definitely
> apply the motion before the transform if both are present. Also, I
> think that implies that the rotation is calculated at the time motion
> is applied - i.e. before the animateTransform is applied to the object.
> 
> Cheers,
> Alex
> 
> --Original Message--:
>> Someone marked 'animate-elem-30-t' as passing for a nightly build of WebKit. This is not correct!  WebKit "fails" on this test since the beginning of this discussion. Means there are just two SVG viewers that should be marked as passing for this certain test. I don't want this test to get removed from the test suite but clarification how to apply the different animations and their transformations to the target element. I agree with Shane Stephens that the current behavior of WebKit makes sense. And I'd also interpret the spec that way. Nevertheless I want to have a common behavior across browsers. I'm fine to change the behavior in WebKit as long as we agree to one of the proposed transformation multiplyings. I also think that this should be clarified before releasing SVG 1.1SE.
>> 
>> Greetings,
>> Dirk
>> 
>> 
>> Am 01.02.2011 um 00:04 schrieb Shane Stephens:
>> 
>>> 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 Tuesday, 6 September 2011 18:22:03 UTC