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"/>

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