Re: [1.2T-LC] 16.2.9 by 'identity' (ISSUE-2093, ACTION-2319)

>> …
>> Therefore it does not help to define what 0 is, because the complete 
>>animation
>> has no meaning, maybe only some error management can be defined for such
>> by animations of non additive types, if it is required to have a defined
>> behaviour.

Cameron:
>Of course.  I might argue that the actual fix should be to ensure
>list-of-length etc. are additive.

Some of them are already explictly mentioned in the attribute/property
definition to be not additive.
For other like text x, y, rotate the length of the list can differ and the 
rules to complete the list are different and partly not trivial.
And just for the last draft version, some types are changed to 
something, what is noted in 16.2.18 to be not additive.

SMIL distinguishes between some additive operation, required
to get some propper values for from-by animations and additive
behaviour, therefore if it is a list of numbers (and variants), 
from-by is still defined, even for non additive attributes, by
animations not.
Interesting to see, that for example the adobe plugin manages
many of them to be additive anyway, even if it is noted in SVG1.1
already, that they are not additive ;o)


>I think transform animations are already a bit weird, because the
>operation being performed for additive/cumulative animations is matrix
>multiplication, not addition.  In that context, saying that the zero
>value is the identity matrix seems appropriate.
>> "To avoid jumps, authors will typically choose animation functions which 
>>start at 0."
>> 
>> If a cumulative by animation starts with 1 instead of 0, this will create 
>> unintended jumps not related to a by animation. This is just another 
>> indication, that 0 is not 1 in SMIL animation too and results in nonsense.

>If addition of transform animations is treated as matrix multiplication
>(which is what the spec says currently), I don’t think this problem
>really exists.

This seems to have historical reasons. Without testing anything,
I think, scaling would be more consistent with having exp(sx),exp(sy)
instead of sx,sy directly in the matrix (but this would exclude mirroring,
but avoids the problem to have no inverse).
If the first terms of the power series is used, then one gets
1+sx, 1+sy, avoiding some surprising animation effects and 
with the possiblity of mirroring again and some matrices
without an inverse.
However, now we have simply sx,sy in the matrix and it is a little bit
late to change ;o)

Cumulative animation is not matrix multiplication, it is simply addition
of the values, this is one of the first steps to calculate the animation
function and is not related to additive behaviour and there is not
specific rule for animateTransform. I think, this was 
always managed consistently in the adobe plugin (and Opera).

If an animateTransform is additive, this means simply, that the
animation effect, the value is calculated according to SMIL.
The result is postmultiplied to the underlying value, whatever
it is. Therefore the specific postmultiplication rule is only important
for the last step to calculate the presentation value  and has 
therefore nothing to do with the initial value of the animation
function, respectively the 0 of a by animation.
Well, it took a longer time for me to understand this too, because
the old SMIL animation recommendation is a little bit confusing
about this, but SMIL2 and 3 define an (almost) clear procedure,
how to calculate the animation effect. The only specific rule
required for animateTransform is, that this effect is postmultiplied
finally. 
And therefore for the type scale by="1,2" clearly corresponds to
values="0,0;1,2" additive="sum". This is completely the same
as for the type transform or rotate correspondingly.
For example the adobe plugin and the current versions of Opera
have implemented this correctly.
That this always starts with a 0-dimensional object is a consequence
only from the function, how the scaling was defined to relate to a 
transform matrix, but is not related to SMIL animation. There is
no consistent way to avoid this without changing the definition of
the scaling matrix as discussed above. And if authors want something
different, they can use a values animation. However, if they do
not start (or end) with a zero scaling, then they will have jumps in
cumulative animations, this cannot be avoided too because of the
definiton of the scaling matrix. 
The definition of skewing has a less dramatic problem, because for
some angles the tangens goes to infinity (no inverse defined for
this, by the way), what could have been avoided with another
function for skewing, but too late now to change...


>Is it relatively simple to identify what 0 is now?  Well, yes, it’s not
>too hard, but I would rather have it explicitly called out, especially
>since we likely won’t be changing to normatively reference SMIL 3 at
>this late stage.

I have no problem, if it is mentioned explictly, but it should be the
right identification and by animation should be applicable at all for
the type ;o)
I suggested already in a previous response, simply to adopt the
by animation definition from SMIL3 in SVGT1.2, then this is already
consistent forward compatible without referencing SMIL3 at all.
This can be removed again in a future SVG version, referencing
SMIL3 already.


Olaf

Received on Thursday, 30 October 2008 13:31:37 UTC