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

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

Received on Thursday, 25 October 2007 13:07:39 UTC