Re: SVG animateMotion specification clarification request

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 Friday, 3 June 2011 10:14:06 UTC