Re: [web-anim] automatically discarding animations

Hi François,

(2012/08/07 18:10), François REMY wrote:
> |  How so? You can drop a sequenced or parallel group as soon as it becomes
> |  inactive.
>
> The whole concept of becoming inactive is broken in the case of seekable
> items. Because a script could seek back the animation at any time (even
> when it finished) it could still return to an active state.

The children (not descendants) of the effects timeline are removed from 
their parent immediately once they finish. So, you can seek them, but 
they won't become active again (without a parent time, they can't).

> |  I guess you're saying we couldn't drop any of the children of the group
> |  until the group itself finishes since you might want to seek the group?
> |  That's a fair point but I think it's ok since I don't imagine there will
> |  be additional long-running top-level groups created in the effects
> |  timeline.
>
> What if one of the animations of the group has "fill: forwards"? This
> seems a pretty frequent case to me that authors would use a special
> transition to an effect and, in the same group, a long-running
> animation. I don't like to make guess about how API are going to be used
> by developers.

Yes, I agree. The long term solution is state machines. Shane Stephens 
has a proposal for this but it's something we decided to drop from the 
first version and focus on the core model. State will be layered on top.

For now, the effects timeline addresses some simple uses but I agree it 
needs work. I think the discussion here is helping to work out some of 
the problems.

I re-read your previous mail about (non-)seekable groups. I think the 
hasSeekableParent property actually needs to look right up the tree.

e.g. if you have:

  Seekable (group)
    Not-seekable (group)
      Not-seekable (animation)

According to the algorithm in the previous mail, once the animation 
finishes you could drop it. But you can still seek the ancestor group 
which would, I think, you give you unexpected results.

The model I'm proposing is that the root effects timeline is not 
seekable but all children are. We drop children (not descendants) when 
they become inactive.

i.e.

   Not-seekable (timeline)
     Seekable (group)  <-- Drop from this point
       Seekable (animation)

I share your concern about fill: forwards and I agree state machines are 
the way to solve this. I wonder if we can work the effects timeline into 
something useful in the meantime.

One alternative is to prevent all seeking of the effects timeline and 
its descendants and re-work reverse to spawn a new animation. That would 
let implementations optimise fill: forwards by replacing such animations 
with a single value.

> Also,
> if you're keeping a reference to the animation for your script to be
> able to reverse() the animation, it can't be removed from memory,
> either.  You would still need to manage the memory on the JavaScript
 > side with an AnimationEnd event.

That's not necessary. There will be APIs in the CSS integration spec for 
querying the animation objects in the timeline or corresponding to 
specific CSS rules. On the mouseout event, you can fetch the appropriate 
animation object, call reverse, and immediately drop the reference to 
the object.

At any rate, there's no need to wait for AnimationEnd before dropping 
the reference to the object. The parent group it is attached to will 
keep it alive until it finishes running.

> We should probably provide a better way to handle state transitions than
> just leave the developers alone on that matter.

Yes, I agree. Shane has a proposal for this which we want to incorporate 
in the future.[1]

Thanks again François!

Brian

[1] 
http://www.w3.org/Graphics/fx/wiki/Advanced_CSS_Transitions_%26_Animations_Proposal
(Not sure if this is the most accurate link. Shane might be able to 
provide an updated one.)

Received on Wednesday, 8 August 2012 00:08:47 UTC