Jump to content
GreenSock

Jeremy Rudd

Why is the Tween not initialized the moment its created?

Recommended Posts

Hi,

 

This is another architectural question, and relates to the starting part of the tween. In the code I'm looking at (GSAP v10), activate() and initTweenVals() is called on the first render(), and then the tween is marked as inited and not inited again.

 

Why is activate() not done in the constructor itself? What are the implications of such a design? Would this cause errors in the tweening engine or the way its used?

 

Yes, I understand that in the present system the tween is initialized on the next enterFrame event (ie. the frame after its created), but are there any advantages to doing it like this? What if the tween were inited on the same frame?

 

Thanks

Link to comment
Share on other sites

Absolutely, there are huge implications. We cannot record all the starting values (most of what activate() does) in the constructor because then tweens with a delay wouldn't work correctly. Imagine if you set up 2 sequenced tweens, both that affect mc.x. It starts at 0 and the first tween animates it to 100 and then the second animates it to 200. If we record the values in the constructor, they would BOTH record 0 as the starting point, so the first tween would work correctly, and then the second tween would make mc.x suddenly jump all the way back at 0 and start again, animating to 200. Not good :)

 

Another implication is overwriting behavior. I don't have time at the moment to explain all the intricacies of managing overwriting behavior, but it can be a thorny issue to wrestle with elegantly. That's why most tweening engines out there don't deal with it at all. They just leave it to you and it can be frustrating especially for beginners. Like imagine a button that does a 2-second (yuck) scale up to 2x normal size, and then on rollout, there's a 1-second scale back to normal size. If you quickly roll over and then back off, most engines (without proper overwrite management) would animate it back to normal size and then suddenly JUMP to halfway through the first (scale-up) tween, and your button would end up in the wrong state!

 

Lastly, it's a performance optimization. Some tweens may get overwritten before they even start, so why spend all that time activating, recording starting values, etc. until the tween actually has to render something for the first time? Imagine creating 1000 tweens inside of a for...in loop, many of which have varying delays. Would you rather bog down the Flash player with all that instantiation code on that one frame (likely causing a noticeable hiccup during playback) or defer them until they're necessary, which in this case would be spread out over many frames?

 

Anyway, I hope that helps clear up why you can't just activate() in the constructor.

  • Like 1
Link to comment
Share on other sites

I understand now. So since easing is not always started now (it could be started later with a delay) its impossible to save start values on this frame.

 

And the overwriting / performance optimization is incredible as well.

 

Thanks a lot.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×