- From: Patrick Schmitz <cogit@ludicrum.org>
- Date: Tue, 5 Jun 2007 22:32:51 -0700
- To: "Sjoerd Mullender" <sjoerd@acm.org>, "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
- Cc: <www-smil@w3.org>
- Message-ID: <ENEGINNFOHPGHPIICCFJOECFEHAB.cogit@ludicrum.org>
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
Received on Wednesday, 6 June 2007 05:33:06 UTC