W3C home > Mailing lists > Public > www-svg@w3.org > March 2002

RE: "to" animation question

From: Patrick Schmitz <cogit@ludicrum.org>
Date: Mon, 18 Mar 2002 17:52:23 -0800
To: Antoine Quint <antoine@graougraou.com>, www-svg@w3.org, www-smil@w3.org
Message-id: <ENEGINNFOHPGHPIICCFJGEKLCDAA.cogit@ludicrum.org>
Well, perhaps I do not understand what you are really trying to do. I will
guess: you want to have each of the animations go from the last activated
one to the desired destination value, and you do not want the current one to
restart when they click again, right?

I expect you already dismissed the restart attribute, since you do want to
restart the animations - just not if they were the last one to run, right?

Basically, you need something to disable the each button after it has been
clicked, and until another button has been clicked. If you can make the
object unclickable until another button has been clicked, this would be
ideal. Barring that, here is one solution:

You do this with a proxy element and some fancy timing. Here is the
pseudo-code; you can translate to SVG. Note that the set proxy elements will
have no animation effect - they are just doing timing.

<button id="50" .../>
<button id="100" .../>
<button id="150" .../>
<button id="200" .../>

<set id="proxy50" restart="whenNotActive"
     begin="50.click" end="100.click; 150.click; 200.click" />
<animate to="50" begin="proxy50.begin" dur="0.1s" fill="freeze" />

<set id="proxy100" restart="whenNotActive"
     begin="100.click" end="50.click; 150.click; 200.click" />
<animate to="100" begin="proxy100.begin" dur="0.1s" fill="freeze" />

<set id="proxy150" restart="whenNotActive"
     begin="150.click" end="50.click; 100.click; 200.click" />
<animate to="150" begin="proxy150.begin" dur="0.1s" fill="freeze" />

<set id="proxy200" restart="whenNotActive"
     begin="200.click" end="50.click; 100.click; 150.click" />
<animate to="200" begin="proxy200.begin" dur="0.1s" fill="freeze" />

This is kind of a weird inverse of the EXCL semantics in SMIL 2.0.
Unfortunately, it does not scale well to a lot of animations, but for a
small set it should work.


> -----Original Message-----
> From: Antoine Quint [mailto:antoine@graougraou.com]
> Sent: Monday, March 18, 2002 10:38 AM
> To: cogit@ludicrum.org; www-svg@w3.org; www-smil@w3.org
> Subject: RE: "to" animation question
> Hi Patrick,
> > At first blush, I believe that the observed behavior is
> > correct. When an
> > animation restarts, it does not create a new instance in the animation
> > sandwich. "to" animations are defined to use the underlying
> > value as the
> > beginning point. When you restart the "200" animation, it
> > must first stop
> > the first instance; this removes the effect of the first
> > instance from the
> > animation sandwich. The underlying value reverts to 50, and so the new
> > instance of the "200" animation effectively replays the last
> > animation as
> > you described.
> Well, that's a little annoying. Have you got any pointers as to how I
> may solve this problem? I can see a workaround using the DOM to actually
> check if my animation should be activated, but I would hope to see a
> solution using straight SMIL Animation.
> One thing I don't understand though is why it reverts to the preceeding
> value in that particular case when it always uses the preceeding
> animated value in other cases. For instance:
> 1) click on 50
> 2) click on 200
> 3) click on 100
> 4) click on 200
> This sequence goes smoothly, it seems that at every new animation the
> implementation checks for latest animated value (lastValue) and emulates
> a <animate from="_lastValue_here_" to="200" ... />. Why in that case
> does it fallback on the one before last animated value? I need a little
> explanation as I just don't get it. Anyway, I really think the effects
> are a little surprising compared to the SMIL code I've written, although
> that's a simple user's opinion, I probably miss something. Thanks for
> your help on that,
> Antoine
Received on Monday, 18 March 2002 20:53:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:54 UTC