[SMIL30 LC comment] more about the fill attribute

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[SMIL30 LC comment] more about the fill attribute

Dr. Olaf Hoffmann

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


Reply | Threaded
Open this post in threaded view
|

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

Thierry Michel


 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 [hidden email] 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@...
 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.


----



Reply | Threaded
Open this post in threaded view
|

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

Dr. Olaf Hoffmann

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


This is more interesting as I expected initially ;o)
PAD is not really useful to avoid the problem.
With this example neither PAD nor AD is a multiple integer of
the simple duration:

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

PAD is 0.5s
AD is 4s
IAD is 3s

Using PAD means, the frozen value is red.
Using AD results in an undefined behaviour,
because the animation does not repeat, there
is no value at 4s.
What one might expect is a blue frozen
value, because this is the last value of
active duration. This fits to the
SMIL animation recommendation or to SVG,
but not to SMIL 2 or 3 :-(


Another one:

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


PAD is 1.5s  -> green
AD is 0.5s -> red
last value of active duration is red,
this is what one might expect for
SMIL animation recommendation or for SVG.


A problem only occurs, if there are
specific rules deviating from
'the last value of active duration'
from the SMIL animation recommendation
or SVG.

For such a deviation/'simplified' rule, a
problem occurs, if min is larger as the
IAD and PAD.
Only then, a selection as the following
one is required:
"
If AD >= IAD and AD >= PAD,
then: 'if IAD is a multiple integer of
the simple duration...'
else 'if AD is a multiple integer of
the simple duration...'
"

However, if the formulas are fixed as suggested, there is no
need for a specific rule anymore, this can be reduce to an
informative note to implementors to simplify/clarify the
situation for them.


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


This does not solve any problems concerning backward incompatibilities
with the SMIL animation recommendation  04-September-2001
3.3.5 and the derived definitions in SVG 1.0/1.1/ Tiny 1.2.

I agreee, that it is both well defined in SMIL2/3 and the
SMIL animation recommendation  04-September-2001 and in
SVG 1.0/1.1/ Tiny 1.2, but due to the addition of the formulas in
SMIL 2 it got incompatible (only) for discrete animation and
related situations, therefore the formulas in SMIL2/3 are not
usable for animation in SVG or for implementations depending
still on the  SMIL animation recommendation  04-September-2001,
because they have to behave in a different (more useful and
intuitive) way as SMIL2/3 implementations.

A better approach avoiding such incompatibilities was already
suggested in the original comment.


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

The end point exclusive nature of timing cannot be used for the current
formulas in SMIL2/3, because they use another (currently incomplete) model,
therefore such a situation is not covered by the formulas.
I think, a similar situation appears with

calcMode="discrete|linear|spline"
values="0;1;2;3;4"
keyTimes="0;0.5;0.5;0.5;1"

This can indeed been avoided using the SMIL time interval model to
fix the incompatibilities in the formulas as already suggested.









Reply | Threaded
Open this post in threaded view
|

Re: [SMIL30 LC comment] more about the fill attribute ( LC-1828)

Thierry Michel
In reply to this post by Dr. Olaf Hoffmann


 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 [hidden email] if
you agree with it or not before 20 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@...
 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 (LC-1828):
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).  It seems that
the relevant parts of the animation chapter were written before the
introduction of the min attribute in the Timing and Synchronization
chapter and this addition was never properly propagated.  The working
group has fixed the situation by using the intermediate active duration
and the active duration to define the frozen animation function.

- 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. Note that this is
similar to a sequence of elements which is cut short just when a new child
is supposed to start.

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


----



Reply | Threaded
Open this post in threaded view
|

Re: [SMIL30 LC comment] more about the fill attribute ( LC-1828)

Dr. Olaf Hoffmann

....

> Working Group Resolution (LC-1828):
> There are three parts to this comment:

In general it is only one issue - backwards compatible
and well defined behaviour for fill...


>
> - When bringing the min attribute into the mix, the definition of the
> freeze value becomes counter-intuitive (to say the least).  It seems that
> the relevant parts of the animation chapter were written before the
> introduction of the min attribute in the Timing and Synchronization
> chapter and this addition was never properly propagated.  The working
> group has fixed the situation by using the intermediate active duration
> and the active duration to define the frozen animation function.
>

The definition and procedures for min and max seem to be taken
from the 'SMIL animation recommendation  04-September-2001'
and this was consistent with the fill value behaviour and propperly
defined including consistency with the SMIL interval timing model
in the old recommendation. This one has indeed its own problems,
but not related to min, max or fill ;o)

The inconsistencies and problems were introduced with the
formulas for fill, obviously not using the timing model and
obviously incomplete too. Therefore for a historical view the
problem is not related to min and max, it is only related to
the formulas in SMIL2/3 for fill ;o) And those formulas are
obviously created later than the definition of min and max in the
'SMIL animation recommendation  04-September-2001'.

But using IAD and AD as suggested in my previous comment,
indeed this can complete the formulas in a useful way.
Obviously it depends on the wording, definitions and formulas,
not accessible to me, to analyse or to decide, if they do it in
a consistent and useful way.



> - 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. Note that this is
> similar to a sequence of elements which is cut short just when a new child
> is supposed to start.
>

This does not solve any problems concerning backward incompatibilities
with the SMIL animation recommendation  04-September-2001
3.3.5 and the derived definitions in SVG 1.0/1.1/ Tiny 1.2.

To resume the pros for the different methods:

a) limes/time interval method as suggested:
- backward compatible with 'the SMIL animation recommendation
  04-September-2001'
- compatible with SVG 1.0/1.1/ Tiny 1.2 and no problems to be expected for
  future SVG versions. No necessary overwrite rules or specific
  considerations in SVG required to ensure backwards compatibility and using
  newer SMIL recommendations for details
- intuitively understandable and simple
- possible to derive any behaviour from one simple rule and the SMIL timing
- respects the SMIL time interval model and uses it
- formulas to simplify correct implementation can be derived and provided as
  informative notes without any problems.

b) formulas from SMIL 2/3
- the WG saves work and time to fix the formulas and to write errata



So, what to do, if the WG thinks, the advantage of b) is much more important
as that of a)?

In this case I would suggest to add an informative note to the formulas, that
the behaviour defined in SMIL 2/3 is backward incompatible to that defined
in the SMIL animation recommendation  04-September-2001.
Therefore implementors of both or on profiles still depending on the
SMIL animation recommendation  04-September-2001 are informed, that
they have to implement a switch depending on the used version.
Authors get informed, that they have to decide between the different
profiles to get the behaviour they need. Authors from other specifications
may take this note as a hint to write overwrite rules to prevent backwards
incompatibilities in their specifications.

Well, I do not think, that this really solves the real problem, but it
simplifies to work around the incompatibilties in SMIL with a certain
amount of additional work for any interested group ;o)



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

The end point exclusive nature of timing cannot be used for the current
formulas in SMIL2/3, because they use another (currently incomplete) model,
therefore such a situation is not covered by the formulas.
I think, a similar situation appears with

calcMode="discrete|linear|spline"
values="0;1;2;3;4"
keyTimes="0;0.5;0.5;0.5;1"

This can indeed been avoided using the SMIL time interval model with
method a) to fix the incompatibilities in the formulas as already suggested.

In case of solution b) (see above), however the WG cannot avoid some
additional work here providing even more specific formulas to cover
such exotic situations just for completeness, because the current model
indeed excludes the SMIL timing interval model for somehow
discontinuous animation effects.