Re: [web-animations] Making players stop

Hi Kevin,

(2013/11/07 2:12), Kevin Doughty wrote:
>>> There was also a naive attempt to enforce arbitrary order for
>>> scale, rotate, and translate transform operations, which failed.
>
>> I'm not sure what this refers to. Who attempted this? What was the problem?
>
> It was a naive attempt of mine, completely wrong. I am still struggling with getting a specific order of those pesky non-commutative transform operations. But this problem is not specific to web-animations so I cannot bother you with it any further.

We looked at how we might offer a fixed order for these operations but 
have yet to come up with any concrete proposal.[1]

>>> When they are done the ticking should stop, and resume if new animations are added.
>
>> Again, this is option C, assuming the group is the only thing attached to the player.
>> Does that sound right?
>
> Yes! But I would rather not use groups at all. Groups seem to be mostly intended for pre-planned and complicated arrangements, for things like art or advertisements. For me, their use only makes sense as a workaround for API where my intended uses conflict with the typical use case. I don’t like the fact that you can alter an animation in progress.

I'm pretty sure we need the ability to manipulate animations on the fly 
since that's currently how SVG works. (But that's not really defined 
anywhere and probably not very consistently implemented so it might be 
negotiable.)

>>> I would be forced to use private API to clean up animations not contained in a group:
>>> anim.onend = function() {
>>> 	if (anim.parent) anim.remove();
>>> 	else anim._player._deregisterFromTimeline();
>>> }
>
>> You can simply drop all references to the animation and it will be garbage collected.
>
> I was wrong and got animations and players confused. It is the players that don’t get removed. If I don’t use the underscored implementation details of the polyfill to remove the thousands of players, there is a performance hit.

Players can also be garbage-collected once they have finished playing if 
there are no references to them. If the polyfill isn't doing that then 
we should try to fix it.

> It seems like a pretty tough job to do since I am asking you for both 1. never remove things so I can continually add to them willy-nilly, and 2. be psychic and automatically remove things when I’m done with them. It seems like it has to be one or the other.

I think the current setup does that. The way the API is defined:
- If you hold a reference to an animation or a player it won't be 
garbage collected.
- Likewise, if you hold a reference to a player or a group that points 
to an animation, that animation won't be garbage collected.
- If a player/animation/group is 'current' (this is defined in the spec 
and basically means it is playing, scheduled to play, or could 
conceivably play again if, for example, the iteration count of a parent 
changed) it won't be garbage collected--even if there are no references 
to it from script.

Other than that, animations, players etc. can be garbage collected (but 
it is up to the implementation if and when it does this).

 > Maybe a way to remove players could be made public?

I don't think we need this currently. However, when we come to SVG we'll 
need to introduce an additional 'SVG' timeline whose contents will 
always be current since SVG allows seeking all the animations in the 
fragment at once. In that case we might need a way to specifically mark 
animations as 'finished' similar to removeOnCompletion or something like 
SVG 1.2's playbackOrder=forwardOnly.

>>> On the subject of using private API, I also have difficulties when copying animations from one element to
>>> another.
>
>> I don't understand what the difficulties are.
>
>> You can clone animations using clone().
>> Or if you just want to clone the timing you *used* to be able to just
>> pass anim.specified to the constructor of another animation
>> (since Timing and TimingInput had the same members)
>> but we broke that when we introduced timing function chains.
>> We'll hopefully find a way to fix that.
>
> The difficulties are using underscored implementation details. I’m pretty sure this is required to preserve timing so a copy of an animation that is halfway finished is also halfway finished:
> newTiming.delay = ((oldAnimation._player.startTime + oldTiming.delay) - document.timeline.currentTime);

There's no need to use '_player' there. Just use 'player'.

To keep the animations in sync but independent, just use:

   newAnimation.player.currentTime = oldAnimation.player.currentTime;

>>> Here is the copying code from the fiddle. Getting the correct timing delay is a bit tricky.
>
>> I'm not sure about the current state of the polyfill but I *think* you should be able to do this as follows:
>> [ . . . code samples . . . ]
>> Does that work?
>
> A quick copy and paste of that code failed, but of course I need to investigate a bit more. I especially like the oldAnim.localTime part, which I had overlooked. It’s good to know either I am doing something wrong or at the very least something should work in the future.
>
> The following fiddle removes thousands of players like this:
> anim.onend = function() {
> 	if (!anim.parent) anim._player._deregisterFromTimeline();
> }
> You can drag the mouse indefinitely without problems.
> http://jsfiddle.net/ghpXu/
>
> The following fiddle does not remove players, and eventually if you drag the mouse long enough animation will come to a crawl.
> http://jsfiddle.net/FbkDZ/

That's likely to be a problem with the polyfill not tidying up.

> But I am not opposed to having to put animations in groups to prevent having to manually remove players, if that is a natural consequence of the API.

Again, there's nothing in the API that necessitates using groups for the 
purpose of garbage-collection.

Best regards,

Brian

[1] http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0043.html

Received on Friday, 8 November 2013 02:12:08 UTC