Re: [css3-transforms] ... to-animation

Dirk Schulze:
...
>
> I somehow agree. It needs to be defined what the underlying value is, 

This you get for free from SMIL, there is nothing to define, this belongs
to the core principles of SMIL, sandwich model etc
http://www.w3.org/TR/SMIL3/smil-animation.html#animationNS-SimpleAnimationFunction

'Animations may be defined to either override or add to the base value of an 
attribute. In this context, the base value may be the DOM value, or the 
result of other animations that also target the same attribute. This more 
general concept of a base value is termed the underlying value. Animations 
that add to the underlying value are described as additive animations. 
Animations that override the underlying value are referred to as non-additive 
animations. The animation effect function  of an element is the function 
which includes the effect of the underlying value and accounts for repeating 
and freezing of the element. Because the animation effect may be affected by 
repeating and freezing, it is defined over the active duration of the element 
rather than its simple duration.'

Basically you need the underlying value already for additive animations.
The viewer has always to administrate a priority list of all animation
functions to determine, what the underlying values is at the time of
interest.

In case of to-animation this (time dependent) value is used as the 
as one value in the interpolation formula, therefore it is essential
to get the effect of to-animations at all.
To define it in a different way would simply mean to corrupt the
core use cases of to-animations, which are similar to CSS transitions.


> then 
> we can allow to-animation [1]. The problem that I see, is that the
> underlying value can be animated as well. 

This is not a problem, it is the main point of interest for to-animation,
therefore and for the frozen behaviour they are special and 
interesting. Else it would be pretty boring to use it at all.


> Therefore the addition on 
> transform functions can cause a performance impact, since in a lot of cases
> the decomposing of the underlying value must be done on every animation
> step.

This may happen for additive animations as well, but ok, those are only
postmultiplied. At least for animateTransform you need no decomposition,
therefore to problem with this processor time consuming approach.


>
> > Because the CSS draft assumes anyway, that it is reasonable that
> > the viewer should have a capability to analyse the structure of
> > two consecutive values in a values list, it should be reasonable
> > as well, that it can analyse whether the underlying value of a
> > to-animation is of the same type as the to-value is.
> > I think, for SVG1.0 - 1.2 it was not considered, that a viewer
> > needs have such a capability, therefore no surprise, that
> > trouble occured here, what is solvable now with advanced
> > capabilities.
> >
> > Rule 1:
> > If it is the same type, simply animate between the underlying
> > value and the to-value with the type that is noted for to-value
> > using the usual SMIL method for to-animations.

This should be extended of course with the cases, that the
underlying value is identified with the identity matrix. In such
a case, this rule should be applied as well.

> >
> > This behaviour can be observed anyway in current viewers
> > with a meaningful interpretation of to-animations, therefore
> > it seems reasonable, that a viewer can do this.
> > And I think, it will cover already a lot of ideas, authors
> > have in mind for to-animations.
>
> I agree on that rule.
>
> > Rule 2:
> > If they are not of the same type, convert both to matrices
> > and interpolate between the matrices. The type for the
> > to-value is only used to convert the value to a matrix.
> > Use for these matrices the usual SMIL method for to-animations.
>
> I agree on that as well, but fear to run into performance issues here, if
> the underlying value is animated as well. 

This happens always for to-animations for other attributes and properties
as well - typically authors will have only few animation for one property
or attribute. I had already performance issues with a single animation
of stroke-dasharray. It will be always possible to create complex SVG files,
that can/will cause performance problems. One cannot avoid this on
the specification side, authors have to care about this to keep documents
simple enough to be presentable with usual processors.

> E.g CSS Animations calculates 
> start and end keyvalues at the beginning of the animation. So you don't
> have the decomposing on every animation step.

SMIL has the begin- and end-time list administration already to control
the priorities, one has only to check for a change additionally, if there
is an event in such a list, but one has to do it anyway to keep the
complete animation effect correct.

>
> > This is more or less only a fallback for this more
> > problematic case, maybe not really important for
> > most authors anyway.
> > Obviously this has limitations for authors, for example
> > if the to-value is of type rotate, there will be not
> > difference between values like -180, 180, 540.
>
> But just on matrix decomposing. It would work for the following example:
>
> <rect transform="rotate(0)" ...>
>   <animate attributeName="transform" to="720" dur="10s"/>
rotate(720) presumable?
> </rect>
>
> The rect would get rotated twice.

This is already covered by rule 1, rule 2 applies only, if the type changes.


>
> > But at least one gets the intended effect for
> > continuous to-animation, a smooth change from
> > the underlying value to the to-value.
> > I think, using decompostion will not result in
> > something much better, especially because
> > the inversion problem may occur again.
> >
> >
> > Minor problem one has to face (as an author) with this:
> > If a lower priority animation is ended before
> > the end of the to-animation, and fill of this is not
> > freeze, a new underlying value may appear,
> > that has another type. In this situation of
> > course the viewer has to reconsider, whether
> > rule 1 or 2 has to be used. But typically this
> > is not really a big additional problem, because
> > typically this end without freeze will result
> > anyway in a discontinuity and the author will
> > not get a smooth change anyway.
>
> But might be for the implementation; performance wise. W might need
> feedback of implementers here. It makes no sense to allow to-animations
> when no one can use them.

I think, currently the Gecko implementation for to-animations in general is 
already quite advanced, what means less bugs than for example with Opera ;o)
But bugs of viewers are currently still quite normal for animation features -
the quality still is on a low to intermediate level and the bugs can be quite
different for different viewers and in different area, unfortunately.
Several of these problems can be identified as comprehension problems,
some others seem to indicate a too simple concept, some are only
simple bugs. All of this can be fixed of course.


Olaf

>[1] 
http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-animation.html#animationNS-ToAnimation

Received on Tuesday, 5 June 2012 11:17:08 UTC