RE: frozen value for discrete animation

Thanks for locating this Sjoerd - this was the part of the spec I was
thinking of that discusses how to deal with the apparent disconnect between
end-point-exclusive segments and reasonable specifications of things like TO
values. While it may not look pure to some readers, I think we got the
semantics right in the spec.

Patrick
  -----Original Message-----
  From: Sjoerd Mullender [mailto:sjoerd@acm.org]
  Sent: Tuesday, June 05, 2007 12:49 PM
  To: Dr. Olaf Hoffmann
  Cc: www-smil@w3.org; cogit@ludicrum.org
  Subject: 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