What is the point of GC'ing TweenLite instances?

[Jeremy Rudd]

Hi all,

 

Currently TweenLite marks completed tweens for garbage collection by setting gc=true.

 

This gc var is later detected by the enterFrame function and the tween is removed from the masterList array using splice.

 

Is there any specific reason its done like this? Could this not have been done directly in the complete() function?

 

Thanks

[GreenSock]

First, it's a speed optimization. Sometimes the user restarts a tween or reverses or whatever onComplete, so if we splice() right away we'd have to drop it right back in again which would be a waste of time. Secondly, it's a functional requirement - if there are any loops happening that involve the masterList and array gets changed like that, it can mess up the order of operation and cause a tween to get missed in the loop or hit twice. For example, imagine on loop 20 of a 50-element loop, some operation causes a tween to complete (due to code in the loop) and then a splice() occurs on the very array that's getting looped over - see the problem?

 

Good questions.

[Jeremy Rudd]

Very intelligent design. You really think far ahead.

 

"If there are any loops?"

Do you mean loops in user code?

 

Or loops in the TweenLite engine itself? Becasue in the v10 code I'm reading, it is the updateAll() function that either calls render() or deletes the tween. So if render() spliced a tween, would it not be just as good/bad as updateAll() splicing the tween?... Except that updateAll() would splice the tween the next frame (the frame after it got over), whereas splicing immediately would splice the tween this frame.

 

Unless things are more complex in v12 that I'm not aware of?

 

And since we're on the topic can you give me an example use case of the user restarting the tween? I can't imagine restarting a tween once its over (unless you need looping animations)

[jamiejefferson]

Here's a (rough) example of a repeating tween:

 

I have a button with opacity 0.7, and the opacity needs to repeatedly tween to 1 while it is hovered.

var hovered = false;
var buttonHoverTween = TweenMax.fromTo(button, 1, { opacity: 0.7 }, { opacity: 1, onComplete:replayButtonHover });

function over() {
   hovered = true;
   buttonHoverTween.play();
}
function out() {
   hovered = false;
}
function replayButtonHover() {
   if (hovered) buttonHoverTween.restart();
}

 

It would be a horrible effect, but maybe you get the idea?

[Jeremy Rudd]

Okay, but I'm still interested in knowing about the loops thing.

[GreenSock]

Very intelligent design. You really think far ahead.

 

Do you mean loops in user code?

 

Or loops in the TweenLite engine itself? Becasue in the v10 code I'm reading, it is the updateAll() function that either calls render() or deletes the tween. So if render() spliced a tween, would it not be just as good/bad as updateAll() splicing the tween?... Except that updateAll() would splice the tween the next frame (the frame after it got over), whereas splicing immediately would splice the tween this frame.

 

Unless things are more complex in v12 that I'm not aware of?

 

First of all, yes v12 is more complex and capable. I would HIGHLY recommend moving away from v10. Some architectural issues were addressed since v10 too.

 

Anyway, to answer your question, I meant loops in the engine itself. Trust me - people can tend to write code that you'd never anticipate when they're using the engine, like a tween that uses an onComplete to then restart itself and force a completely different tween to completion that is later (or earlier) in the very loop that you're in the middle of (masterList). I've learned to try really hard to anticipate issues and build the architecture to handle almost anything that's thrown at it (although I can probably never do a perfect job of anticipating every possible scenario).

 

As far as v10's splicing on the next frame instead of the current loop, yeah, that can be a very useful tactic. Like I said, what if a tween completes and then another one activates it on the same frame? It would get spliced and then added back in and that can be a dangerous thing when you're in the middle of a loop and the index number (or array length) is getting messed with.

 

And since we're on the topic can you give me an example use case of the user restarting the tween? I can't imagine restarting a tween once its over (unless you need looping animations)

 

You'd be surprised how many times people do this sort of thing. Some may not want to use TweenMax's repeat functionality because they must use TweenLite due to file size constraints, so they fake the repeat functionality with an onComplete that does a restart().

[Jeremy Rudd]

Understood. So its for both reasons. Unpredictable user code and reactivation (enable = true) of deleted tweens that makes it better for TweenLite to defer the deletion until its actually needed.

 

Great job, Jack. No one would suspect the amount of thought-work that goes into everything.