W3C home > Mailing lists > Public > www-smil@w3.org > July to September 2007

[SMIL30 LC comment] more about the fill attribute

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Wed, 5 Sep 2007 14:02:30 +0200
To: www-smil@w3.org
Message-Id: <200709051402.30979.Dr.O.Hoffmann@gmx.de>

Hello SMIL working group,

there is an inconsistency in 
the behaviour of the fill attribute
in SMIL 3 (and SMIL 2).
The discussion was already started
for SMIL 2 ( for example
http://lists.w3.org/Archives/Public/www-smil/2007JanMar/0017.html
and the following)
but was not finished 
yet and applies to the LC of
SMIL 3 as well.





First assume this example with a video 
having only 3 frames:

[0s;1s) : red frame
[1s;2s) : green frame
[2s;3s) : blue frame

<video src="3sRGB3frames" 
   alt="video with 3 frames; duration 1s per frame; frames: red, green, blue" 
   dur="3s" begin="1s" end="3s" fill="freeze" />

.... and a related animation example:

<animate attributeName="color" 
   values="red;green;blue" 
   calcMode="discrete" fill="freeze"
   dur="3s" begin="1s" end="3s" />

Presentation without an end attribute is therefore in both cases:
[1s;2s) : red
[2s;3s) : green
[3s;4s) : blue
and later blue too.


To get the correct behaviour with the end attribute 
lets resume some sections:


11.4.5

The instance times lists

'offset-values are the simplest. Each offset-value condition 
yields a single instance time. This time remains in the list 
forever, and is unaffected by reset of the element, or by 
repeat or restart of the parent (or other ascendants).'

Examples above
-> instance time list for begin: 1s
-> instance time list for end: 3s

11.4.3

Dur value semantics

'dur
Specifies the simple duration.'

Examples above
-> simple duration: 3s


The fill attribute

'For visual continuous media, the "frame" that 
 corresponds to the end of the last instance of the 
 simple duration is shown.'
 
 
-> what is the 'end of the last instance of the
     simple duration'?
     A duration is not directly related to a moment in time.
     In the video example above the simple duration 
     is related to an interval [1s;4s).
     Instances seem to be related to
     moments, not to (time) intervals.
     Therefore if an instance is only a moment
     it is obscure what the end of this moment is.
     
     The related end is at 3s. This is the last end
     instance time according to 11.4.5.
     But this does not answer, what the end
     of the last instance of the simple duration is.
     1s the begin, 3s the (exclusive) end of the
     interval related to the (cut off) simple duration. 
     
     If 'last instance' nevertheless is meant to be
     related to intervals (the last repetition of 
     the simple duration?), the 'frame' 
     corresponding to the end of the last
     instance of the simple duration is
     the green frame in the video example
     above.
     
 
'For algorithmic media like animation, the value 
 defined for the end of the last instance of the 
 simple duration should be used.'
 
 -> what is the 'value defined for the end of 
      the last instance of the simple duration'?

     Here we have almost the same arguments
     for the animate element as for the
     video element. The simple duration 
     is related to an interval [1s;4s).
     Instances seem to be related to
     moments, not to (time) intervals.
     Therefore if an instance is only a moment
     it is obscure what the end of this moment is.
     
     The related end is at 3s. This is the last end
     instance time according to 11.4.5.
     But this does not answer, what the end
     of the last instance of the simple duration is.
     1s the begin, 3s the (exclusive) end of the
     interval related to the (cut off) simple duration. 
     
     If 'last instance' nevertheless is meant to be
     related to intervals, the value
     corresponding to the end of the last
     instance of the simple duration is
     the color green in the animate example
     above.

 -> This looks as a 'good' interpretation, because it fits to the 
      definition of the fill attribute in the 
      SMIL animation recommendation  04-September-2001
      http://www.w3.org/TR/2001/REC-smil-animation-20010904/ 
      3.3.5:
     
     'freeze 
      The animation effect F(t) is defined to freeze the effect 
      value at the last value of the active duration.'
      
->  Because the active duration interval is inclusive begin
      and exclusive end the frozen value is green.
      
->  Because SVG 1.0/1.1/ Tiny 1.2 use the same definition,
      this is consistent with them too.
      
->  In SMIL 1.0 I could not find any detailed description
      for the fill behaviour related to the video example.
      
      
However there is a problem with the SMIL3 section  3.4.5 ...  
freezing animations. 
The formulas given in this section are consistent with 
this interpretation if calcMode is linear, paced or spline 
(There is an exception related to animateMotion using 
the path element, see below), but not always if it is
discrete.
With these formulas the frozen value of the
animation example above would result in blue and 
not green. 
Therefore there is a probable contradiction between
SMIL 3 Chapters  11.4.3 and 3.4.5 and there
is an obvious incompatibility between SMIL 3
Chapter 3.4.5 (respectively SMIL2) and the 
 SMIL animation recommendation  04-September-2001    
 3.3.5 and the derived definitions in SVG 1.0/1.1/ Tiny 1.2.
 
 This causes already some confusion in SVG Tiny 1.2,
 because this references already SMIL 2.1, but the 
 inconsistent formulas cannot be used, because they
 do not fit to the its definition of fill for calcMode
 discrete.
 
 Therefore my suggestion is to do some minor changes to
 the normative section for fill in SMIL 3.0, 3.4.5 and 
 to add an errata to SMIL 2 to fix this problem.
 Unfortunately the specific rule for the case where the
 active duration is a multiple integer of the simple
 duration can be found already in the 
 SMIL animation recommendation  04-September-2001,
 therefore to avoid compatibility problems, this has to
 be taken into account too.
 
 The change could be something like this:
 
 old:
 'Normative
 The frozen animation function, ff(t), 
 for an element with active duration AD, is given by
 ff(t) = fc(t) for all times t: 0<=t<AD (i.e. before it is frozen)
 When the element is frozen, t is effectively equal to AD.
....' (etc)
 
 new:
  'Normative
  The frozen animation function, ff(t), 
  for an element with active duration AD, is given by
  ff(t) = fc(t) for all times t: 0<=t<AD (i.e. before it is frozen) and
  ff(AD)= limes (e>0 to 0;   fc(AD - e)) 
  with the following exceptions:
  If AD is an multiple integer of d, i.e. AD = d*i for some positive integer 
i , 
  and the animation is non-cumulative, ff(t) = f(d).
  If AD is an multiple integer of d, i.e. AD = d*i for some positive integer 
i , 
  and the animation is cumulative, ff(t) = f(d)*i.
  
  Informative
  If the limes is elaborated, this results in the following rules.
  
 For calcMode[reference related section] linear, paced and spline
 (and no animateMotion with path fragments separated from each 
 other):
 
 When the element is frozen, t is effectively equal to AD.
 ...' (etc)  
 
 and additionally:
 
 'For calcMode discrete (or animateMotion with 
 path fragments separated from each other):
 The frozen value is the last value of active
 duration. Note that the active duration is related to a
 time interval with inclusive begin and exclusive end.
 Therefore if the end of active duration meets exactly
 the time, the animation jumps to a new value, this jump
 does not take place. The only exception to this is a
 keyTimes value of one and the active duration
 is an integer multiple of the simple duration, then the
 value related to keyTimes 1 is used as a frozen value
 respectively the multiple of the value for cumulative 
 animations as defined above.'
 
------------------------------------

Details about the problem with
animateMotion using paths with several M/m 
commands...

To identify this we can use the following 
example:


<animateMotion calcMode="paced"
 path="M100 100 m100 100l100 100
            m100 100l0 0 
            m100 100l100 100 
            M0 0"
dur="6s"
fill="freeze" 
repeatDur="as specified" />

If repeatDur is not specified at all we get
the following motion:

time [0s;3s) motion from 200,200 to 300,300
time [3s;6s) motion from 500,500 to 600,600
frozen value at 6s and later: 0,0
(M 0 0 creates a bad or empty interval of length
zero, but defines the last value of the animation,
this is similar for calcMode paced and
path fragments like 'm100 100l0 0' or
'm 100 100z', always ignored in the animation,
if this is not the last path fragment and the
active duration is not an integer multiple of 
the simple duration. However for calcMode
linear (or spline) path fragments like 
'm100 100l0 0' or 'm 100 100z' take their 
fraction of time, the motions stops in this 
time interval).


Now we assume repeatDur="3s"

time [0s;3s) motion from 200,200 to 300,300
frozen value at 3s and later: 300,300

As we can see, this behaviour is somehow
related to a discrete animation and the 
formulas in SMIL 3.0, 3.4.5 have another
problem related to the path fragments of
zero length. Because the time 3s can be
related to three values:
300,300; 400,400; 500,500

The suggested and consistent limes rule
from above avoids such problems using 
simply the SMIL time interval model. 


 --------------------
 
Another minor problem with the formulas for the fill attribute
in 3.4.5:
 
To identify this, we can use the keyTimes 1 example from
3.9.1:

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

Lets assume an additional min="21s".
This is the case in 11.4.3 (min/max):
'... otherwise the element is played normally for its 
repeating duration (or simple duration if the element does not repeat) 
and then is frozen or not shown depending on the value of the fill attribute'

Now the active duration is 21s, therefore not an integer multiple of the
simple duration 10s anymore. 

But in 3.4.5 'Freezing animations'
this exotic situation is not described, because neither the
animation function at 21s nor at 20s is formally defined.
Maybe now the frozen value has to be 1 for the non cumulative case 
and 3 for the cumulative case just due to the SMIL time interval
model because there is no other specific rule. Correct? 
Maybe, but probably not intended.
Maybe this requires an additional note or a precision, for example
that the frozen behaviour is determined as if the active duration is
not corrected with the min attribute, if the corrected active duration
is not smaller as the uncorrected active duration.
Not nice to implement, but somehow another side effect of this 
'multiple integer' rule...
Received on Wednesday, 5 September 2007 12:04:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:53:29 GMT