Re: [SMIL30 LC comment] more about the fill attribute

 Dear Dr. Olaf Hoffmann ,

The SYMM Working Group has reviewed the comments you sent [1] on the Last
Call Working Draft [2] of the Synchronized Multimedia Integration Language
(SMIL 3.0) published on 13 Jul 2007. Thank you for having taken the time to
review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at www-smil@w3.org if
you agree with it or not before 02 nov 2007. In case of disagreement, you
are requested to provide a specific solution for or a path to a consensus
with the Working Group. If such a consensus cannot be achieved, you will
be given the opportunity to raise a formal objection which will then be
reviewed by the Director during the transition of this document to the
next stage in the W3C Recommendation Track.

Thanks,

For the SYMM Working Group,
Thierry Michel
W3C Staff Contact

 1. http://www.w3.org/mid/200709051402.30979.Dr.O.Hoffmann@gmx.de
 2. http://www.w3.org/TR/2007/WD-SMIL3-20070713/


=====

Your comment on Synchronized Multimedia Integration Language (SMIL 3.0)
W...:
> 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...


Working Group Resolution:
There are three parts to this comment:

- When bringing the min attribute into the mix, the definition of the
freeze value becomes counter-intuitive (to say the least).  The solution
which the working group proposes (and has implemented) is to change from
using the active duration to using the preliminary active duration.  In
this way, the functions work the way they were originally intended to
work.  The preliminary active duration is the active duration before the
effect of min and max has been taken into account.

- When an animation is cut short and then frozen, the frozen animation
function uses the time at which the freeze starts instead of (as is usual
in e.g. frozen videos) the "last" value of the still active time.  The
working group decided to leave this the way it is.  The functions are all
well-defined and don't need any further refinement.  The fact that this is
perhaps counter-intuitive with respect to the end point exclusive nature of
SMIL timing is offset by the clarity of the functions.

- When multiple move commands with zero-length lines happen at the same
instance of time (when using paced animation), the last of these move
values is the one that is used for freezing at that time.  The end point
exclusive nature of timing already suggests that the zero-length lines all
end their duration before this time instance.  In your example, the value
on which the animation would freeze is then 500,500.  This is in line with
the previous point.


----

Received on Tuesday, 23 October 2007 09:08:35 UTC