Re: SVG animateMotion specification clarification request

On Mon, Jan 31, 2011 at 2:49 PM, Ken Stacey <ken@svgmaker.com> wrote:
> On 28/01/2011 8:14 AM, Shane Stephens wrote:
>>
>> In case the previous messages were tl;dr, what is the expected
>> behaviour of this snippet? :-)
>>
>> <svg xmlns="http://www.w3.org/2000/svg">
>> <rect width="20" height="20" transform="translate(100, 100) scale(2,1)">
>>   <animateMotion path="M 0 0 c 0 150 150 150 150 0" begin="0" dur="3"
>> fill="freeze" rotate="auto"/>
>>   <animateTransform attributeName="transform" type="scale" from="1 1"
>> to="1 2" begin="0" dur="3" additive="sum" fill="freeze"/>
>> </rect>
>> </svg>
>>
>> If I label:
>> * the transform provided by the rect's transform attribute as RT
>> * the animateMotion path component as MP
>> * the animateMotion rotation component as MR
>> * the animateTransform scale as AS
>>
>> (I think) the specification indicates that the correct resulting
>> transform is given by: RT * AS * MP * MR, and that this should be true
>> regardless of the order of the animateTransform and animateMotion
>> elements.
>
> I agree.  The spec does say that.
>
>>
>> This is the current behaviour of Batik, and (as of a few months ago)
>> WebKit trunk.
>>
>> However, the expected result of animate-elem-24-t.svg indicates that
>> the animateMotion path component should come before the
>> animateTransform transform if the elements are ordered as above.
>> There's no animateMotion rotation component in animate-elem-24-t.svg,
>> so according to that test valid orderings could be:
>> RT * MP * AS * MR, or
>> RT * MP * MR * AS.
>>
>> The first of these is the current behaviour of Opera, and again this
>> is the case regardless of the order of the animateTransform and
>> animateMotion elements.
>
> I think Opera (and ASV) is the latter - RT * (MP * MR) * AS.  At least for
> your example above.

Ah, yes, you are correct, at least as far as Opera is concerned.  I
haven't tested ASV.  The following:

<svg xmlns="http://www.w3.org/2000/svg">
  <rect width="20" height="20" transform="translate(100,100) scale(2,1)">
    <animateMotion path="M 0 0 c 0 150 150 150 150 0" begin="0"
dur="3" fill="freeze" rotate="auto"/>
    <animateTransform attributeName="transform" type="scale" from="1
1" to="1 2" begin="0" dur="3" additive="sum" fill="freeze"/>
  </rect>
  <rect width="20" height="20" transform="translate(200,100) scale(2,1)">
    <animateTransform attributeName="transform" type="scale" from="1
1" to="1 2" begin="0" dur="3" additive="sum" fill="freeze"/>
    <animateMotion path="M 0 0 c 0 150 150 150 150 0" begin="0"
dur="3" fill="freeze" rotate="auto"/>
  </rect>
  <rect width="20" height="20" transform="translate(300,100) scale(2,1)">
    <animateMotion path="M 0 0 c 0 150 150 150 150 0" begin="0"
dur="3" fill="freeze"/>
    <animateTransform attributeName="transform" type="rotate"
from="90" to="-90" begin="0" dur="3" additive="sum" fill="freeze"/>
    <animateTransform attributeName="transform" type="scale" from="1
1" to="1 2" begin="0" dur="3" additive="sum" fill="freeze"/>
  </rect>
  <rect width="20" height="20" transform="translate(400,100) scale(2,1)">
    <animateMotion path="M 0 0 c 0 150 150 150 150 0" begin="0"
dur="3" fill="freeze"/>
    <animateTransform attributeName="transform" type="scale" from="1
1" to="1 2" begin="0" dur="3" additive="sum" fill="freeze"/>
    <animateTransform attributeName="transform" type="rotate"
from="90" to="-90" begin="0" dur="3" additive="sum" fill="freeze"/>
  </rect>
</svg>

Illustrates the invariance with ordering of animateMotion and
animateTransform, as well as the fact that the animateMotion rotation
occurs before the scale, not after.

>
>> This is actually quite odd behaviour (the
>> order of application is always any container transform, followed by
>> any animateMotion path components, followed by any other animation
>> components, followed by any animateMotion rotation components), but I
>> guess it's stood for a while as this is a fairly crusty corner of the
>> spec.
>>
>> Note that neither Batik nor WebKit trunk pass animate-elem-24-t.svg;
>> yet both (as far as I can tell) implement the specification correctly.
>>  It'd be great to get some clarification on whether
>> animate-elem-24-t.svg is incorrect; or alternatively whether the
>> specification will be updated to reflect this test, so that I can
>> ensure WebKit remains as compliant as possible with the specification.
>
> There does need to be some clarification.
>
> animate-elem-53-t.svg is another example of inconsistency between the spec
> wording and expected behavior wrt combining animateTransform and
> animateMotion.
>
> Since I have built a lot of SVG SMIL generating code which assumes the
> Opera/ASV behavior, I would vote for a change to the spec.  For me, it seems
> more useful/intuitive to apply animateMotion before animateTransform. But
> I'm not sure that is because it is genuinely more intuitive or because I'm
> used to it being that way.

I also think a spec change is a good idea - however I would rather see
us put an end to the 'supplemental' nature of animateMotion
altogether, and have both the translation and the rotation appear in
listed order in the CTM.  Your example below would still work with
this change.

Sincerely,
     -Shane Stephens

> As an example, think of how you would compose an animation where a
> circle pulsates (scales) as it moves along a path.
>
> If I didn't think much about it, I would write something like
>
> <circle r="20">
>  <animateTransform attributeName="transform" type="scale"
> values="1;0.75;1;1.25;1"
> begin="0" dur="0.5s" repeatCount="6"/>
>  <animateMotion path="M 0,0 l 400,400" dur="3" fill="freeze"/>
> </circle>
>
> As per the wording in the spec, that wouldn't work like I want, and I would
> have to do some nesting as Olaf suggests. Something like
>
> <g>
>  <circle r="20">
>    <animateTransform attributeName="transform" type="scale"
> values="1;0.75;1;1.25;1"
> begin="0" dur="0.5s" repeatCount="6"/>
>  </circle>
>  <animateMotion path="M 0,0 l 400,400" dur="3" fill="freeze"/>
> </g>
>
> The need to nest here feels wrong... I think.
>
> Ken Stacey
>
>>
>> Sincerely,
>>     -Shane Stephens
>>
>> On Mon, Jan 24, 2011 at 12:32 AM, Dr. Olaf Hoffmann
>> <Dr.O.Hoffmann@gmx.de>  wrote:
>>>
>>> Hello,
>>>
>>> well, this looks interesting, therefore I had a look on this.
>>>
>>> Just my own observation/interpretation/results about this
>>> issue:
>>>
>>> The behaviour for the animateMotion attribute rotate
>>> is defined as well to be supplemental transformation matrix
>>> onto the CTM of the animateMotion effect - I think, this is the key to
>>> find out, what the originally intended behaviour was - and what
>>> a meaningful/useful behaviour could be.
>>>
>>> If we assume, 'supplemental transformation matrix
>>> onto the CTM' means the same for the rotate effect related
>>> to the motion effect related to an additional transformation effect,
>>> the behaviour of rotate auto is indeed the key to understand the
>>> intended behaviour.
>>> The intention is, that it should align the x-axis into the
>>> motion direction.
>>>
>>> To simulate this with animateTransform, one has to
>>> postmultiply the rotation to the translation.
>>>
>>> To be consistent, the correct behaviour should be
>>> with an additional animateTransform to postmultiply
>>> the motion to the transformation and to postmultiply
>>> the rotation to the motion.
>>> Additionally the transform attribute is defined to
>>> behave like this:
>>> "The ‘transform’ attribute is applied to an element before processing any
>>> other coordinate or length values supplied for that element."
>>> This seems to indicate as well, that both the motion and
>>> rotation have to be postmultiplied to the transform effect.
>>>
>>> And indeed, in my test example I created, this seems
>>> to be the most useful behaviour - I used an additional
>>> animateTransform of type rotate to test this.
>>>
>>> However  animate-elem-24-t seems to indicate something
>>> different - and in the implementation reports more viewers
>>> pass this than fail.
>>> Batik/Squiggle seems to be consistent here for example
>>> and postmultiplies as expected - I think, this is correct, but
>>> is indicated to fail in the implementation report.
>>> The behaviour of Batik/Squiggle however looks meaningful/useful
>>> for my test. Opera and the adobe plugin for example have
>>> implemented the order as implicated by animate-elem-24-t
>>> and this does not look meaningful/useful for my test case -
>>> they do not align the x-axis of the moved object into the
>>> motion direction anymore.
>>> Because the adobe plugin was an early implementation,
>>> this could be the source of the surprising behaviour of
>>> several viewers and the animate-elem-24-t ;o)
>>> Maybe animate-elem-24-t was not intended to test, whether
>>> the implemented behaviour is meaningful in general, therefore
>>> with this test (without rotate auto) it is not easy to identify that
>>> it implicates a surprising/inconsistent behaviour.
>>> The test could be improved.
>>>
>>> I think, the test and the related sample images (anim01) of the
>>> recommendation and most viewers behave inconsistent here
>>> compared to the description.
>>>
>>> Therefore indeed, this needs some clarification from the
>>> working group ....
>>> Either it should be clarified that the rotation is postmultiplied to
>>> the motion and this premultiplied to the transformation
>>> (there could be reasoning additionally to explain, why this is useful -
>>> main application could be to transform the moved object additionally
>>> instead of transforming the coordinate system of the moving object)
>>> or it should be clarified, that the motion is postmultiplied to
>>> the transformation and the rotation is postmultiplied to the
>>> motion - in this consistent case bugs in many viewers as
>>> well as the anim01.svg of the recommendation and animate-elem-24-t
>>> need to be fixed.
>>>
>>> Until all this is clarified or fixed, it is easy for authors to avoid the
>>> current problem by nesting additional transformations within additional
>>> g elements. With such a construction, authors can always decide
>>> about the order of such effects - maybe this is the reason, why it
>>> was not very interesting, what was typically implemented - if needed,
>>> authors worked around the ambiguity with additional nesting of groups ;o)
>>>
>>>
>>> Olaf
>>>
>>>
>>>
>>>
>>
>>
>
>

Received on Monday, 31 January 2011 04:29:33 UTC