Re: Fwd: SVG animateMotion specification clarification request

Hi Shane,

On 30/03/2011, Shane Stephens wrote:
> Hi Ken,
>
>> A similar problem exists for RT * (MP * MR) * AS. If AS involves
>> translation then the apparent motion path between rotate="auto" and
>> rotate="none" is also different.
>>       ...
>>
>> If you allow animateMotion and animateTransform to be given equal
>> status, then the RT * (MP * MR) * AS scenario suffers the above
>> apparent motion path inconsistency.>
>
> This is true, although I would argue that in this case the difference
> is expected, as it's the same as what happens with any other
> rotation transform followed by a translation transform.

I agree with you that the difference is expected.

For the (MP * MR) * RT * AS case, if you know that this is the matrix 
order then I could argue that the difference is expected there also.  Of 
course, that doesn't make it useful or intuitive.

I think my fixation on the inconsistency of the rotate behavior came 
from a (casual) author point of view.  In the spec you would possibly 
need a warning of some kind that rotate="auto" could produce unexpected 
results when RT... (or AS...)

> With a scheme that allows for RT * AS1 * (MP * MR) * AS2, encoded in
> SVG as (roughly):
>
> <rect transform="RT">
> <animateTransform transform="AS1"/>
> <animateMotion path="MP" rotate="auto"/>
> <animateTransform transform="AS2"/>
> </rect>
>
> there is a clear ordering of transform components reflected in the
> output, and you can do useful things with both AS1 and AS2 in a way
> that is intuitive and consistent with transforms elsewhere in the
> spec (AS1 transforms the motion path, while AS2 transforms the object
> that travels along the path).

I like the idea.

But... if animateMotion and animateTransform are equals, the order of 
begin times also affects the order of application of each animation.

If the begin time for AS1 < AS2 < MP, the matrix order will be RT * AS1 
* AS2 * (MP * MR).  Perhaps not what is expected.

Yet another part of SMIL I dislike.

Through this discussion and other SMIL work I have done, I find the only 
way to construct predictable and complex animations is to nest them in 
<g> elements to force the matrix order I need.

Ken

Received on Thursday, 31 March 2011 03:02:52 UTC