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

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?

>> 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].

>> 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].

>>
>> 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.

>>
>> 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."?
>>
> 
> 

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#AnimationAttributesAndProperties
[2] http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#AnimateTransformElement

Received on Tuesday, 21 October 2008 10:14:11 UTC