ISSUE-2089: animateTransform and underlying value

animateTransform underlying value

animateTransform and underlying value

State:

CLOSED

Product:

SVG 1.2 Tiny: Last Call

Raised by:

Doug Schepers

Opened on:

2008-10-07

Description:

Dr. Olaf Hoffmann
<http://lists.w3.org/Archives/Public/www-svg/2008Oct/0010.html>:
[[
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."?
]]

Related Actions Items:

• ACTION-2307 on Anthony Grasso to Make changes as suggested by DOH for ISSUE-2089 - due 2008-10-23, closed
• ACTION-2308 on Anthony Grasso to Draft an email response for the second half of ISSUE-2089 - due 2008-10-23, closed

Related emails:

1. minutes, SVG WG Sydney 2012 F2F day 3 (from cam@mcc.id.au on 2012-01-13)
2. SVG/profiles/1.2T doc-svgt12.html,1.25,1.26 (from cvsmail@w3.org on 2008-11-04)
3. Re: [1.2T-LC] animateTransform and underlying value (ISSUE-2089) (from Dr.O.Hoffmann@gmx.de on 2008-11-02)
4. [Fwd: Re: [1.2T-LC] animateTransform and underlying value (ISSUE-2089)] (from schepers@w3.org on 2008-11-02)
5. Minutes October 30, 2008 telcon (from ed@opera.com on 2008-10-30)
6. SVG/profiles/1.2T doc-svgt12.html,1.2,1.3 (from cvsmail@w3.org on 2008-10-30)
7. SVG/profiles/1.2T doc-svgt12.html,NONE,1.1 (from cvsmail@w3.org on 2008-10-28)
8. SVG/profiles/1.2T/master animate.html,1.131,1.132 (from cvsmail@w3.org on 2008-10-22)
9. Re: [1.2T-LC] animateTransform and underlying value (ISSUE-2089) (from anthony.grasso@cisra.canon.com.au on 2008-10-22)
10. SVG/profiles/1.2T/master animate.html,1.129,1.130 (from cvsmail@w3.org on 2008-10-21)
11. Re: [1.2T-LC] animateTransform and underlying value (ISSUE-2089) (from anthony.grasso@cisra.canon.com.au on 2008-10-21)
12. SVG/profiles/1.2T/master animate.html,1.125,1.126 (from cvsmail@w3.org on 2008-10-19)
13. Minutes, SVG Marathon telcon Friday October 17 2008 (from anthony.grasso@cisra.canon.com.au on 2008-10-18)
14. Re: Logistics of Open Issues (from schepers@w3.org on 2008-10-16)
15. Logistics of Open Issues (from schepers@w3.org on 2008-10-16)
16. Minutes October 16, 2008, marathon telcon (from ed@opera.com on 2008-10-16)
17. Re: [1.2T-LC] animateTransform and underlying value (ISSUE-2089) (from schepers@w3.org on 2008-10-07)
18. ISSUE-2089 (animateTransform underlying value): animateTransform and underlying value [Last Call: SVG 1.2 Tiny ] (from sysbot+tracker@w3.org on 2008-10-07)

Related notes:

Display change log