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

Hi Olaf,

On Jun 4, 2012, at 3:15 AM, Dr. Olaf Hoffmann wrote:

> Dirk Schulze:
>> 
>>> Only for to-animations there is a specific behaviour defined.
>> 
>> To animations are not supported on CSS Transforms, the same like for
>> 'animateTransform'. If you have a good suggestion how to animations are
>> supposed to work. I am happy to define it.
>> 
> 
> What is written in SVG tiny 1.2 about this (and copied to SVG 1.1.2), 
> was just a result from the issue, that for unknown reasons the type matrix 
> was not animatable and there was not much motivation to clarify the
> situation, this was simply delayed to the next version.
> However with the CSS draft the matrix type becomes animatable and
> this can be considered as a new version/variant for SVG transform,
> therefore to avoid the situation, that this is forgotten and undefined
> again, we should clarify it now.
> And if we look into the definition of to-animation in SMIL 2/3, this
> finally is a clarification of the original animation recommendation, 
> current versions of SVG still refer to - the normative behaviour of
> to-animations is not defined to be additive at any time, therefore 
> no conflict with post-multiplication of SVG animateTransform.
I somehow agree. It needs to be defined what the underlying value is, then we can allow to-animation [1]. The problem that I see, is that the underlying value can be animated as well. 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.

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

> 
> 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"/>
</rect>

The rect would get rotated twice.

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

Greetings,
Dirk

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

Received on Monday, 4 June 2012 16:52:20 UTC