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

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

Received on Tuesday, 7 October 2008 11:40:53 UTC