Re: Proposal: Fix frozen to-animation

Brian Birtles:
> Dear Olaf,
>
> Thank you very much for your response! I will follow it up below.
>
> 2011/3/25 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>:
> > The proposed behaviour is available already, if no to-animation is
> > used, therefore if authors need this behaviour, they can simply use
> > values animations.
>
> I do not believe it is already available. If we have:
>
>   <animate attributeName="y" values="100; 50; 100; 150; 100" dur="2s"
> repeatDur="indefinite"/>
>   <animate attributeName="y" begin="a.click" to="100" dur="2s"
> repeatCount="0.75" fill="freeze"/>
>
> I would like to clamp this animation gradually to 100 with a
> to-animation, but should the clamping function finish part-way through
> its simple duration it should constrain the underlying animation to
> the extent that it is applied. I'm not aware of a way to achieve this
> result with values animation without knowledge of both the underlying
> animation function and without synchronisation with its timing.

What about
  <animate attributeName="y" values="100; 50; 100; 150; 100" dur="2s"
  repeatDur="indefinite"/>
   <animate attributeName="y" begin="a.click" values="0;100" dur="2s"
   repeatCount="0.75" fill="freeze" additive="sum"/>

Of course, it is not exactly the same, because it has not 
the specific behaviour than a to-animation, however it starts with the 
underlying value and freezes with additional 75. Of course, this does
not cover the underlying value, but I think, this is your intention, while
that of the to-animation is, that the frozen values covers all animations
with lower priority.

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.

>
> Admittedly, the currently defined behaviour also cannot be achieved
> with other constructs (since it too depends on the values and timing
> of the underlying animations) but I believe the currently defined
> behaviour is both less intuitive and less useful and if it is
> required, easier to simulate (with a set animation given the
> appropriate to value).
>

How?
I think, one has to determine the resulting value for the 'freezing' time
manually and has to set this at this time to cover other things.
Because I have written several tests about to-animations I know,
that it will be not easy for many authors to calculate the resulting
value of a to-animation at an arbitrary time, if there are
animations with lower priority contributing to the resulting value.
And this still does not contain the option to 'conserve' some
not explictly known value (Ok, due to bugs, this does not really
work with current implementations, but is implicated with the
complete to-animation-feature).
This would be an option for a new set of animation elements
for SVG to get such a conversation feature more directly.
For example to get it from someElement:
<getValue  id="myValue" xlink:href="#someElement" attributeName="fill"
   begin="60s" />
And later to set it:
<setValue xlink:href="#someOtherElement" attributeName="stroke" begin="120s"
   setTo="#myValue" />

 

> > I think, the attempts (as for discrete animation) to change to-animations
> > and the bugs in several current viewers indicates a general misconception
> > of such implementations to treat it as an ordinary animation.
> > ...
> > Because [to animation] is defined to be different to
> > values-animations, it should be no surprise, that it behaves different
> > and needs a different implementation - this is the whole point about it
> > ;o)
>
> This proposal does not attempt to make to-animation behave like other
> animation types. Rather, it makes to-animation consistent with itself.

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.
In SVG there is a remaining problem to understand it for animateTransform,
therefore there was no agreement on what to write about it in SVG.
But basically already SMIL notes, that it is neither additive nor 
non-additive, therefore the postmultipication rule from SVG for
additive animation is not necessarily applicable or only at the begin
time of the animation, not for a finite time interval, therefore it is not
a big problem to fix this gap in SVG and to have the same feature 
available for animateTransform (we can think of different more or
less complex rules to make it more useful for authors or less difficult
to implement for implementors).

Else I cannot see specific gaps or problems related to the definition
of to-animations.
Of course, other animation types could be interesting as well, but
then we should find a way to add such functionality instead of replacing
other already defined functionalities.
The approach of CSS transitions is more general, maybe interesting
to add such a functionality to SVG/SMIL animations, because currently
with CSS is is less useful anyway, because a state like ':hover' is not
precisely defined and SVG/SMIL animations are much more flexible
for defining the intended event to start such a transition.


> That is, it removes a special case formula that only applies when a
> to-animation is frozen and instead defers to normal to-animation
> behaviour. (If anything, it makes to animation more special, not
> less.)

Sure, if it would not be special, there would be no need to define
such a specific feature ;o)

Olaf

Received on Friday, 25 March 2011 14:03:35 UTC