Re: frozen value for discrete animation

I don't normally send HTML email, but I need the subscripts.

On 06/05/2007 11:22 AM, Dr. Olaf Hoffmann wrote:

I understand the problem of discrete animations with a keyTimes value of
1 and a freeze and/or repeat in combination with the exclusive end time
model. I think your solution to disallow a value of 1 for keyTimes in
discrete animations has merit. However, I am a bit uncomfortable with
it. My main issue is, how to determine whether an animation is
discrete. If the playback engine does not support interpolated
animations on some value, it treats the animation as discrete, thereby
causing the same problem again.

Another solution might be to specify that in the case of a discrete
animation and a keyTime of 1, the time should be understood to be the
smallest possible fraction *before* the full duration. In that case,
the final value is reached before the end, and all problems are also
resolved. Or am I missing something here?

I think, to disallow a keyTimes of 1 is more related to authors as
to the viewer itself. The author will be forced to think about
a useful value and the SMIL timing model.
If he writes keyTimes="0;0.7;0.9" there is no big problem of
interpretation for him or the viewer. This is independent from the
method the viewer uses to visualise the animation.
This is the same for keyTimes="0;0.7;0.99999999" even if the
viewer is not really able to resolve the last keyTimes for practical
reasons, it is simple to see/to calculate, that the last interval
is from 0.99999999 to 1, therefore with or without repetition it
is simple to calculate the correct animation effect including
frozen and cumulative behaviour just using the SMIL timing
model without any specific rules.
Currently all implementors have to 'construct' or deduce
a specific rule for frozen and cumulative behaviour for
keyTimes 1, mainly just because authors using this by accident
without thinking about a useful value or the problem 1 causes.
Therefore if keyTimes 1 remains as allowed for discrete
animation, one or two informative paragraphs and
carefully choosen examples including frozen and cumulative
behaviour will already help to get a least the same behaviour
in different viewers for this strange situation.
keyTimes 1 requires a specific rule anyway, if allowed.
It is not really important, how the behaviour for keyTimes 1
really is, it is more important, that it is simple to understand
and to implement in a well defined way. Then developers
are not confused/frustrated by authors bug reports. Maybe
authors are still confused by the result of the viewers, but if
it is always the same in different viewers, this should be an
indication, that this is well defined somehow, but keyTimes
1 is not useful at all for discrete animation ;o)

I have to retract my previous suggestion. I now think there doesn't
have to be any change to the normative part of the animation
specification (other than the change of "even multiple" to "integer
multiple"). The reason is that I think it is already properly
specified. This does not mean that there shouldn't be an example. An
example would be useful to explain the situation. i (and with me the
Working Group) am very wary of changing the normative part of the
specification in the way you propose. It may have unforseen
consequences within the SMIL specifiaction and beyond (e.g. in SVG).
Here is my reasoning for not needing a normative change.

Consider the repeating animation

<par dur="30">

<animate calcMode="discrete" repeatCount="2" dur="10" fill="freeze"

accumulate="as specified" keyTimes="0.0; 0.5; 1.0" values="0; 1;
2"/>

</par>

In the table we show the values at different times for the two possible
values of accumulate:

time
accumulate

none
sum

t=0
0
0

t=5
1
1

t=10
0
2

t=15
1
3

t=20
2
4

t=25
2
4

The values at times t=0 and t=5, and the values in the accumulate="none"
column at t=10 and t=15 need no further explanation.

The value at t=10 in the case of accumulate="sum" follows from the
definitions in the section Controlling
behavior of repeating animation - Cumulative animation.

f0(t) = f(t)

fi(t) = (f(d) * i) + f(t - (i*d)) for any
integer i > 0

fc(t) = fi(t), where i =
floor(t/d)

For t=10, i = floor(10/10) = 1, so

fc(10) = f1(10) = (f(d) * 1) + f(t -
(i*d)) = f(10) + f(10 - 10)) = 2 + 0 = 2

Also, remember that f(d) is a shorthand to refer to the
last value defined for the animation function, which in this case is 2.

The values for t >= 20 follow from the next normative section. For
the non-cumulative version, we have: "If AD is an integer
multiple of d, i.e. AD = d*i for some
positive integer i, and the animation is non-cumulative, ff(t)
= f(d)." In other words, ff(20) = f(10) = 2.
For the cumulative version, we have "If AD is an integer
multiple of d, i.e. AD = d*i for some positive integer i,
and the animation is cumulative, ff(t)
= f(d) * i." In this case, i = 2, so ff(20)
= f(d) * 2 = 2 * 2 = 4.

--
Sjoerd Mullender