[Fwd: Re: [1.2T-LC] animateTransform and underlying value (ISSUE-2089)]

Hi, Dr. Olaf-

This was accidentally sent to the SVG WG list instead of the public SVG
list (www-svg), so I'm reposting it here.  Please let us know if you are
satisfied with this response.

Thanks-
-Doug

-------- Original Message --------
Date: Wed, 22 Oct 2008 02:40:58 +1100
From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
To: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
CC: W3C SVG Public Working Group <public-svg-wg@w3.org>

Hi Dr. Hoffmann,

Thank you for your feedback. Please see my comments below.

Dr. Olaf Hoffmann wrote:
> Hello,
> 
> Anthony Grasso:
>> Hi Dr. Hoffmann,
>>
>> The SVG Working Group discussed this issue. Please see my comments below.
>>
>> Doug Schepers wrote:
>>> Hi, Dr. Olaf-
>>>
>>> Thanks for your comment.  I've recorded this as ISSUE-2089 in our
>>> Tracker. The SVG WG will discuss this and get back to you soon.
>>>
>>> Regards-
>>> -Doug
>>>
>>> Dr. Olaf Hoffmann wrote (on 10/1/08 10:19 AM):
>>>> Hello SVG WG,
>>>>
>>>> SMIL notes about the underlying value of an animation:
>>>> "The base value of a target attribute 'a' at time t is the value of 'a'
>>>> to which animation is applied at time t."
>>>> and
>>>> "Animations can be defined to either override or add to the base value
>>>> of an attribute. In this context, the base value may be the DOM value,
>>>> or the result of other animations that also target the same attribute.
>>>> This more general concept of a base value is termed the underlying
>>>> value." and
>>>> "The underlying value u of a target attribute 'a' of an animation
>>>> element at time t is the value of 'a' to which the animation effect is
>>>> applied at time t."
>>>>
>>>> In the table of SVGT1.2 '16.2.18 Attributes and properties that can be
>>>> animated' it is noted for transform:
>>>> "Additive means that a transformation is post-multiplied to the base set
>>>> of transformations."
>>>>
>>>> and in 16.2.17 The 'animateTransform' element:
>>>> "When an animation is active, the effect of non-additive
>>>> 'animateTransform' (i.e. additive="replace") is to replace the given
>>>> attribute's value with the transformation defined by the
>>>> 'animateTransform'.
>>>> The effect of additive (i.e. additive="sum") is to post-multiply the
>>>> transformation matrix corresponding to the transformation defined
>>>> by this 'animateTransform'."
>>>>
>>>> The obvious conclusion is, that the underlying value for an additive
>>>> animateTransform is the base set of transformations at the time t
>>>> and that the result of the animateTransform has to be post-multiplied
>>>> to the underlying value (which includes results from lower priority
>>>> animations too).
>>>>
>>>> Surprisingly 16.2.17 notes too (different from SVG 1.1):
>>>> "The underlying value of transform animations (see SMIL discussion of
>>>> animation function values) is the corresponding identity transformation
>>>> value."
>>>>
>>>> This means especially, following this sentence new in SVGT1.2 compared
>>>> with SVG1.1, that
>>>> a) the underlying value is time independent
>>>> b) the underlying value is always the same
>>>>
>>>> Effectively this sentence prevents any visible effect from additive
>>>> animateTransform in conflict with the table of 16.2.18 and the additive
>>>> sample of 16.2.17 and example: 19_01.svg of 16.2.3 and samples in the
>>>> test suite like animate-elem-81.
>>>>
>>>> My impression is, that it is neither intended that additive
>>>> animateTransform show no difference to non-additive animateTransform nor
>>>> that these conflicts are intended. It looks more like a misunderstanding
>>>> of the meaning of the SMIL definition of the 'underlying value',
>>>> therefore I suggest simply to skip in 16.2.17 the sentence
>>>> "The underlying value of transform animations (see SMIL discussion of
>>>> animation function values) is the corresponding identity transformation
>>>> value."
>> I would like to clarify your suggestion. Do you mean delete _only_ the
>> sentence "The underlying value of transform animations (see SMIL discussion
>> of animation function values) is the corresponding identity transformation
>> value."?
>>
>> The reason I ask this is the following sentence, bullet points and the next
>> paragraph relate to that first sentence. I think if the first sentence is
>> deleted either one of two things has to happen
>> 1) Delete the following bullet points and next paragraph.
>> 2) Reword following sentence before the bullet points and reword the next
>> paragraph.
>>
>> Which do you think would best address the issue? and can you please suggest
>> any wording if option (2) is best?
>>
> 
> You are right, after the changes noted below, the underlying value is defined
> at points in the draft, where it is relevant, for additive="sum".
> 
> Therefore we can take the following fragment:
> 
> -->
> The 'values' attribute for the 'animateTransform' element consists of a 
> semicolon-separated list of values, where each individual value is expressed 
> as described above for 'from', 'by' and 'to'.
> 
> The underlying value of transform animations (see SMIL discussion of animation 
> function values) is the corresponding identity transformation value. Thus, 
> the underlying value for 
> type="translate" is tx = ty = 0
> type="scale" is sx = sy = 1
> type="rotate" is rotate-angle = cx = cy = 0
> type="skewX" and type="skewY" is skew-angle = 0
>  Note that this results in counter-intuitive results for a to animation. Since 
> the underlying value is identity, and the 'additive' attribute is ignored on 
> to animations according to SMIL, such animations will behave like a 
> non-additive from-to animation where the "from" value is identity.
> 
> If 'calcMode' has the value paced, then the "distance" for the transformation 
> is calculated consisting of the sum of the absolute values of the differences 
> between each pair of values as further described in Paced animations and 
> complex types.
> <--
> 
> 
> And replace it with something like:
> 
> -->
> <p>
> The 'values' attribute for the 'animateTransform' element consists of a 
> semicolon-separated list of values, where each individual value is expressed 
> as described above for 'from', 'by' and 'to'.
> </p>
> <p>
> <em>from-to, from-by and by animations</em> 
> are defined by SMIL to be equivalent to the related <em>values animations</em> 
> (see <a 
> href="http://www.w3.org/TR/2005/REC-SMIL2-20051213/animation.html#AnimationNS-FromToBy">SMIL</a>
> ). 
> </p>
> <p>
> The animation effect for animateTransform is post-multiplied to the underlying 
> value for additive animateTransform (see below) instead of added 
> to the underlying value due to the specific functionality of animateTransform.
> </p>
> <p>
> The idea of <em>to animations</em> is a mixture of additive and 
> non-additive behaviour (see <a  
> href="http://www.w3.org/TR/2005/REC-SMIL2-20051213/animation.html#animationNS-ToAnimation">SMIL</a>
> ) providing a specific functionality to get a smooth change from the
> underlying value to the <em>to</em> attribute value, which conflicts
> mathematically with the requirement for additive animateTransform to be
> post-multiplied.<br />
> Currently within SVG tiny 1.2 this conflict is not resolved and therefore the
> behaviour of <em>to animations</em> for animateTransform remains 
> undefined and may result in not predictable behaviour instead of the 
> expected functionality as defined by SMIL for <em>to animations</em>.
> </p>
> <p>
> If 'calcMode' has the value paced, then the "distance" for the transformation
> is calculated as further described in 'Paced animations and complex types'.
> </p>
> 
> <--
> 
> I think, this does not change, what we already have, provides more
> relevant information on what to expect or how to implement, 
> and it does not conceal the remaining problem with the to animation
> (and gives some reasoning, why it is a problem to specify something
> useful for to animations).
> 
> The last paragraph is shortened a little bit, because I discovered, that
> it still contained some confusing stuff, not required anymore, because
> the referenced table covers this completely.
> 

Agreed. This change now appears in Section 16.2.17 [1] of the specification.

> 
> 
> 
> 
>>>> and to explicitly note 'underlying value' in the table of 16.2.18:
>>>> "Additive means that a transformation is post-multiplied to the base set
>>>> of transformations representing the underlying value."
>> Agreed. This change can now be found in the published version of the
>> specification [1].
> 
> yes, ok.
> 
>>>> and in 16.2.17 too:
>>>> "The effect of additive (i.e. additive="sum") is to post-multiply the
>>>> transformation matrix corresponding to the transformation defined by
>>>> this 'animateTransform' to the the base set of transformations
>>>> representing the underlying value."
>> Agreed. This change can now be found in the published version of the
>> specification [2].
>>
> 
> yes, ok.
> 
>>>> Because from-to, from-by and by animations are defined in SMIL already
>>>> to be equivalent to the corresponding values animation (tests are
>>>> already available in the test suite), there remains no specific problem
>>>> for those notations for animateTransform too.
>>>>
>>>> What remains is the problem with to-animateTransform, because this
>>>> animation type is neither pure additive nor pure non-additive.
>>>> The following requirements for to-animations come from SMIL:
>>>> a) begin (additive) with the underlying value
>>>> b) end non-additive with the to value
>>>> c) specific formula defined in SMIL has to be used -
>>>>     the formula defines a specific feature or behaviour or
>>>> functionality, not available with other combinations of animations in
>>>> SMIL/SVG. The main functionality it typically a smooth change from the
>>>> underlying value to the value specified with to
>>>> d) specified attributes additive or accumulate have to be ignored
>>>>
>>>> The following requirement comes from SVG animateTransform
>>>> e) animateTransform has to be post-multiplied to the underlying value
>>>>
>>>> There is especially a conflict between c) and e).
>>>> There are different more or less useful and simple possibilities to
>>>> solve this conflict.
>>>> 1) If e) is skipped, this requires an animation of the complete
>>>> transform matrix in general to meet c) - this might be not completely
>>>> trivial but is possible. Mainly one has to express the underlying value
>>>> as a matrix as well as the value of the to attribute and to interpolate
>>>> between those two values as specified in SMIL to get the desired smooth
>>>> change. Because to-animations behave always quite different from
>>>>      the other animation types, this does not create any inconsistency.
>>>> 2) If c) is skipped, this results in the complete loss of the
>>>> functionality of to-animations for animateTransform. If we accept this,
>>>> possibilities could be
>>>>      2.1) to define to-animateTransfrom always to be a discrete
>>>> animation, this avoids a direct conflict between c) and e) too, because
>>>> SMIL defines the behaviour of discrete to animation not conflicting with
>>>> e), therefore to-animateTransform has effectively the same functionality
>>>> as a set animation, not directly available for transform currently. 2.2)
>>>> to define an arbitrary initial value as done by the current draft, using
>>>> effectively the identity transformation as initial value. This provides
>>>> no interesting functionality as well and means, that a) has to be
>>>> skipped as well due to the problem with the underlying value as
>>>> discussed above.
>>>>      2.3) to specify that to-animateTransform has no effect, to
>>>> indicate, that not all requirements can be met.
>> We agree that this is an outstanding issue since SVG Tiny 1.1. We intend on
>> doing a comprehensive review and address this issue in the next version of
>> the SVG specification.
> 
> I included the 'undefinition' already in the suggested wording above ...
> 
> 
>>>> Side note:
>>>> In the table of 16.2.18 there are two notes about color conversion.
>>>> This looks like a missing word:
>>>> "Only additive if each value can be converted an RGB color."
>>>> ->
>>>> "Only additive if each value can be converted (in)to an RGB color."?
> 
> What about this missing word?
> 

Oh sorry, this has now been fixed in Section 16.2.18 [2].

> 
> 
> 
> Olaf
> 

Please let us know at your earliest convenience if the changes are
satisfactory.

Kind Regards,

Anthony Grasso.


[1]
http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#AnimateTransformElementTypeAttribute
[2]
http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#AnimationAttributesAndProperties

Received on Sunday, 2 November 2008 15:58:42 UTC