Re: [web-animations] Making players stop

Thanks for taking my concerns seriously, despite their unreliability. I made some mistakes and I was not very clear or helpful.


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


>> As it is now, I need a both-filling and zero duration ParGroup 
>> that does not tick away until animations are appended by user interaction.

> This sounds like you want Option C from [2]. Currently, players always tick away.

I really did read what you wrote, I swear, thank you for the extra help!


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

Line 245 of the shim describes what I was trying to do:
// TODO: Remove dead Players from here?

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. Maybe a way to remove players could be made public? That and a way to copy timing, then I would care if different group behavior other than C was chosen.


>> 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);

I do not mind having to type lots of extra stuff. All I really care is that it is possible, especially since this will not be available once web-animations is implemented natively in the browser.

The clone() function seems more like a convenience for developers to create new animations, dealing with Javascript object copying issues. It seems to me that in those cases it would very easy to track the few values used to create the initial animation, and use the constructor instead of cloning. What isn’t easy is preserving timing by tracking potentially thousands of start times for my use case.


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

I tried to make an example that puts all of the animations into a single group. I had a working version a long time ago, but I can no longer get this to work via:
timing.delay = document.timeline.currentTime;

I don’t know why it didn’t work but I don’t want to delay my response any longer. Anyway, I abandoned that approach because there was a performance penalty. 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.

I seem to be full of unreliable information, I hope you can find something relevant.

Received on Wednesday, 6 November 2013 17:13:18 UTC