Re: Proposal: Fix frozen to-animation

Brian Birtles:
> Dear Olaf,
>
> Thanks very much for your feedback will I'll respond to below.
>
> 2011/3/25 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>:
> > Can you provide a formula for what you think, the frozen value
> > of your variant of a to-animation should look like?
> > Because to-animations are not additive, it is not obvious, how the
> > formula for another behaviour should look like. The current rule
> > for the frozen state seems to be the simplest variant for me.
> > SMIL provides a formula for each time of the to-animation.
> > To define another variant, we need something like this to compare.
>
> The point of this change is not to add a variant but to remove one.

Unfortunately this would remove possible applications as well,
therefore not a good idea from the authors point of view ;o) 

>
> For SMIL Animation the formula given is:
>
> f(t) = v_cur + ((v_to - v_cur) * (t/d))
>
> Essentially, we just want to continue applying that formula when the
> animation is frozen. Unfortunately this is complicated by the fact
> that v_cur is defined as "the current base value (at time t)" which is
> inaccurate because:

As several other bugs/ambiguities in the old SMIL animation
recommendation, this is fixed in later versions of SMIL, which
have in the average less bugs, because they fix a lot of those
issues and introduce only one (?) new inconsistency. 
Therefore in doubt it helps to look into them, if a problem
cannot be solved with the old SMIL animation recommendation.
Because SVG 1.1 still depends on this old recommendation,
the situation is somehow unsatisfactory currently, but typically
it is simple to work around the inconveniences.

>
> (a) it should refer to the underlying value, not the base value (the
> base value refers to the target attribute's un-animated value whilst
> the underlying value refers to the result of the animation sandwich up
> to this point).
>
> (b) t is defined as "a time within the simple duration (0 <= t <= d)"
> but clearly we don't use a time within the simple duration when
> determining v_cur. (See SMIL 3.0 which divorces t from the underlying
> value)

This problem applies for all frozen animations and is discussed and
defined in SMIL.

>
> For these reasons it's hard to provide an accurate formula using the
> same terms as SMIL Animation. What we really want to say is that the
> given formula continues to apply even when the animation is frozen. It
> is the same formula. Of course, as with all frozen animation, the
> value of t will remain fixed, but v_cur should continue to change.
>
> These inaccuracies have been addressed in subsequent editions of SMIL
> and for SMIL 3.0 we can simply drop the f_f(t,u) = v_f formula[1] to
> get the desired result.

Whose desire?

I think, for values-animation one can simply calculate an animation
effect without taking into account questions about additivity or priorities.
After this is done, one can decide about additivity and priorities separately.

For to-animation, because it is neither additive or not-additive, one has
always to use the specific defined algorithm to get the intended
effect, therefore it works anyway different from values-animations,
including the frozen value. The complete effect is not additive,
why should the frozen value suddenly be additive, this is not
intuitive and does not fit to the model of the to-animation.


>
> > I cannot see the inconsistence within the definition of to-animations.
> > Because it is a specific case, it is described in detail. There are still
> > a few things in SMIL, which are not consistent with itself or with
> > previous versions of SMIL, we alreadey tried to avoid this in SVG tiny
> > 1.2 for example for specific cases of frozen discrete animations.
> > But to-animations look ok for me in SMIL.
>
> There is additional prose in SMIL Animation and an additional formula
> in SMIL 3.0 specifically to describe behaviour for frozen to-animation
> other than what naturally falls out of the model. 

Which model, because the model for to-animation is quite different
from values-animation, obviously the model of values-animation
never applies for to-animation.

> This is the kind of 
> inconsistency I am concerned about. 

If you have apples and pears, are you concerned about
the different taste as well? :o)


> I understand that this is special 
> behaviour but I cannot see justification for such special behaviour.

Well, I you have a look for example into the CSS transitions draft,
this might give an idea.
It is not perfect either, but indicates, that several people assume,
that something like this has use cases.

For typical use cases of to-animations, the current bugs
in viewers are pretty frustrating and prevent authors from using 
this feature at all (or for more than a trivial use case to save
some letters by using 'to' instead of 'values' ).
There is no improvement for author if only the bugs are defined
to be correct now - the situation remains, the applications do
not work, whatever the reason for this is.


> It seems less useful and less intuitive that what would naturally fall
> out of the model if such formulae were removed.

Then the complete to-animation should be removed, because it
behaves different from values-animations - not a good idea.


>
> >From an implementation point of view, my further concern is that the
>
> currently specified behaviour is not implemented correctly anywhere
> and nor will it ever be. 

The CSS people seem to believe, that something like transitions
are implementable, else there would be more discussion about to
give up this draft.

Maybe the main point about the difficulties with to-animation
is, that implementors try to use model, that is not appropriate to
get the intended effect. 
Because there are already test implementations for CSS transistions
however, on the other hand, some seem to have similar models for
this implemented.

> Many implementations rely on a distinction 
> between timing model and animation model[2], 

It indicates, that they have to use a slightly different animation
model for to-animations ...
This means mainly, that you need a timing model and a
model for values-animations and one for to-animations.

> a distinction encouraged 
> by the SMIL specification itself which defines the two in separate
> chapters. My implementation experience is that implementing this
> correctly requires undesirable coupling between the two models. The
> proposed change allows the distinction between timing model and
> animation model to be preserved.

But it removes possible applications as well.
Before this is done, maybe an advanced model for something like
the CSS transitions should be available in SVG/SMIL animation.
Maybe additionally an option to conserve animation values as
already proposed.
Then indeed, there would be no need for to-animations anymore.

By the way, doesn't values like 'currentColor' and 'inherit' complicate
the model in a similar way? Those can behave similar to to-animations
(ok, the frozen part is excluded here) and some viewers do not
manage them correctly as well.
Those values or 'none' or paint servers for fill and stroke result
in a situation, that viewers do not manage values lists including
such values automatically to determine the calcMode correctly.
Following your approach, this would be an indication to remove
such values from fill and stroke as well to simplify the model and
implementation efforts. For them, indeed concerning animation 
I think, it was not very clever to overload such properties in such a way.
Nevertheless - now it seems to be unavoidable to care about
such complications.

And because there are attempts to convert attributes into properties 
for the next SVG version, doesn't this indicate, that in general the 
simple model is too simple at least for properties and future versions of 
SVG?

Olaf

Received on Wednesday, 6 April 2011 11:08:49 UTC