Help! New GSAP version broke my project due to TweenLite.from usage

[sbarret]

Hello all

 

I'm doing a project where I must tween a number of elements as a "in" transition to the pages.

I was having a number of problems with performance, and the new version of GSAP (GSAP 1.12.0) fixed them! (It's an iPad project)  

 

But...

 

I've extensively used TweenLite.from - since I have all properties on CSS correctly set, and just need to fade and move them in - typical syntax is

TweenLite.from('.example', 1, {opacity:0, y:-200, delay:1});

all this worked perfectly... until the GSAP update.

 

Now the items are visible before the tween starts... (the delay period)... and only when it starts it goes to opacity 0. Before, the properties were set, then tween ran, and the job was done.

 

So I tried to change it:

 

I've create a function that sets the visibility in jquery when the function is triggered:

TweenLite.from('.example', 1, {opacity:0, y:-200, delay:1, onStart:setElementVisible onStartParams:['.example']});

But nope... the initial position flickers on screen before the onStart funcion is rendered... so it doesn't work.

 

Any ideas on how should I proceed to regain the old feature back?

 

Please, do not suggest me to change all tweens to "TweenLite.to" - it would involve changing all CSS of the project, and change all tweens... things were all done here, I was only having performance problems with the lag...

 

Thanks a lot!

[GreenSock]

Sorry to hear about the trouble. Don't worry, we'll get you fixed up, no problem. You won't have to change all your tweens to to()

 

The short answer: try adding TweenLite.render(); after you create all your tweens (the last line)

 

The explanation: the new "lazy" render feature in 1.12.x can really speed initialization up by deferring the rendering until the end of the "tick" cycle. The problem is that you're probably running your code completely outside of that cycle, like in a jQuery.ready() call or something. That's not "wrong" at all, but it messes with the timing a bit because the order may look like this:

1. "tick" starts...
2. GSAP updates/renders all of its tweens (well, the ones that are supposed to render)
3. "tick" ends (this is where the lazy stuff would render)
4. Your code block with all your TweenLite.from(...) calls (after all this code executes, you're expecting the from() state to be rendered immediately)
5. ...some time passes (typically less than 16ms)...
6. next "tick" starts

Notice #4 is outside the tick cycle and there's no way for GSAP to know when your code block is done executing so that it can then render. It does so at the very beginning of the next "tick", but a few milliseconds may have elapsed (that's when you see that brief flash). 

 

We added a TweenLite.render() method exactly for this scenario, so that you can force a render. Drop that TweenLite.render() call at the end of your code and it's like saying "okay, GSAP, I'm done creating all my tweens...go ahead and render stuff (including lazy renders in the queue)." 

 

There are actually several other options (just to be thorough):

1. You could set lazy:false on your from() tweens. That'll prevent them from being lazy with their renders, but the major down side is that if you've got many non-lazy tweens that are initializing on the same "tick", you'll run into the read/write/read/write performance hit that many browsers impose (this has nothing to do with GSAP - it's a browser thing). 
2. You could make sure you're creating your tweens within the "tick" cycle. To do this, simply use a TweenLite.delayedCall() with a super small delay. Remember, delayedCalls are always perfectly synchronized with the entire GSAP engine. 

$(function() { //maybe you're using jQuery to fire when the page loads...
    TweenLite.delayedCall(0.001, function() { //this function will fire on the very next "tick" cycle
        
        //all your animation creation code here...
        TweenLite.from(...);
       
    });
});

Does that help?

 

Oh, and please make sure you download the 1.12.1 update (we found a small bug that could cause a set() tween not to render on iOS devices - that was only introduced in 1.12.0 and was online for less than 24 hours). We're waiting for the CDN to update right now, but the new files are available in the zip and on github now. 

[Steve]

Hi,

I'm having the same issue. I'm using a jQuery.ready. tried adding a .render, and the .delayedCall. Neither worked for me?

 

My tweens are inside an  if ($windowWidth < 692) {.......

 

Any suggestions?

[Carl]

Hi Steve,

 

Sorry to hear you are having trouble.

 

It is difficult to suggest a solution from the code fragment you provided. It would be of great help if you could produce a reduced test case that clearly illustrates the problem. We don't need to see your full production code, just a tween or two that is working properly will suffice.

 

Using CodePen to create an editable demo that we can fork and share works great. Here is more info on how that works: http://forums.greensock.com/topic/9002-read-this-first-how-to-create-a-codepen-demo/