Re: frozen value for discrete animation

> 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)

Received on Tuesday, 5 June 2007 09:23:29 UTC