Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
phidur

immediateRender timeline.set().pause() GSAP 2.0.2 vs 2.1.2

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

In the documentation for the GSAP 2.1 update it says that immediateRender defaults to false for all timeline.set() function calls. So if I need to call timeline.set() on a newly instantiated (zero-duration, unpaused) timeline before adding any tweens to that timeline, are those timeline.set() function calls ever executed if no tweens are added? Are they executed before any newly added tweens? Because the timeline is unpaused, I would expect those timeline.set() calls to execute regardless of what follows and before any subsequently added tweens begin animation. However, this is not what I am experiencing in either case.

 

I can achieve the desired result with immediateRender: true, but this doesn't seem like expected behavior to me. I know this is one of the issues you guys have been wrestling with and some of the immediateRender changes were rolled back in 2.1.2, so I just wanted to make sure I wasn't missing something/this isn't a bug. Thanks and keep up the amazing work!

 

Edit: In case it was unclear, I am using GSAP 2.1.2

Link to comment
Share on other sites

If you're using 2.1.2 and have a set() tween as the only tween on the timeline, it should fire immediately for an unpaused timeline. If the timeline is paused, it will not fire unless immediateRender is set to true.

 

See the Pen BEooBp by PointC (@PointC) on CodePen

Changelog:

https://github.com/greensock/GreenSock-JS/releases

 

Happy tweening.

 

 

  • Like 3
Link to comment
Share on other sites

Hi @PointC, thanks for the response, it has certainly helped me isolate my issue. The discrepancy in behavior that I'm experiencing between GSAP 2.0.2 and 2.1.2 seems to be in relation to placing a timeline.pause() call immediately after timeline.set() - e.g. timeline.set("#box1", {x: 300}).pause()

 

In GSAP 2.0.2, the .set() executes before the timeline is paused. In 2.1.2 this does not seem to be the cause. I forked your codepen to show this. When I change the GSAP version number, I see different results. Are you seeing the same thing? Is this expected? Thanks

 

GSAP 2.0.2:

See the Pen mgeZqE by phidur (@phidur) on CodePen

 

GSAP 2.1.2:

See the Pen eopwpr by phidur (@phidur) on CodePen

 

Link to comment
Share on other sites

  • phidur changed the title to immediateRender timeline.set().pause() GSAP 2.0.2 vs 2.1.2

Yeah, I'm not sure why there's a difference on that. I guess adding the .pause() after the .set() like that is the issue since a .set() is a zero duration tween? But the difference in the two releases is somewhat unexpected. I know the recent changes with immediateRender's default behavior have been a bit confusing so maybe I'm just confusing myself here.  @GreenSock can shed some light for us.

 

Stand by, @GreenSock will probably stop by later today with some info.

 

Happy tweening.

  • Like 1
Link to comment
Share on other sites

I don't see any unexpected behavior, though perhaps I'm misunderstanding something. 

 

immediateRender is false by default for set() calls inside of a timeline as of version 2.1.0. Before that, we used to check to see if the set() call is at the very start of the timeline, and if so we'd default immediateRender to true but that got a little confusing particularly when timelines were nested. It seemed cleaner to just have a consistent default rather than "in this condition, the default is false, but in this other condition it's true...."

 

In your example, the timeline never actually rendered because you paused it right away. Remember, everything updates based on ticks (requestAnimationFrame-driven typically). Normally, on the very next tick the timeline would have updated, the virtual playhead would move, and any tweens (including set() calls) that are positioned between the previous playhead position and its new position would render. But again, in your case, it got paused, so on the next tick nothing rendered in that timeline. 

 

Does that clarify things? 

 

As you said, if your goal is to have it render immediately no matter what, just set immediateRender:true and you should be good-to-go :)

  • Like 1
Link to comment
Share on other sites

I was a bit confused by this because I thought the immediateRender defaults went back to all the old settings with 2.1.2 which would mean a set() as the first tween on the timeline would fire even without immediateRender set to true. That's the behavior @phidur was seeing in his 2.0.2 version.

 

I'm probably just thinking of the from() tween immediateRender default behavior changing from false on 2.1.0 back to true in 2.1.2.

 

My skull is thick so it takes multiple attempts to get any information into my head. ;)

  • Like 1
Link to comment
Share on other sites

Yep, you're right @PointC. The immediateRender:true default for from() and fromTo() tweens in timelines is what reverted. Sorry about the confusion :)

  • Like 1
Link to comment
Share on other sites

Oh, it's not your fault. If I would have read instead of skimmed, I'd have seen this in the release notes:

  • 2.1.2
  • - REVERTED: In 2.1.0, we changed the default immediateRender for **paused** TimelineLite/Max from(), fromTo(), staggerFrom(), staggerFromTo() calls to be false because a few people considered it a "bug" to have a paused timeline render anything (including starting values). However, since releasing 2.1.0, it has come to our attention that the change made a bigger impact on our user base than anticipated and it was a pain point. It altered behavior, so we decided it's better to revert to the old default, and to introduce a change like this in a future major version update. Our apologies for any confusion the 2.1.0 change caused anyone. 2.1.2 restores the old immediateRender defaults. And to be clear, this only ever affected timelines that were paused at the time the from()/fromTo()/staggerFrom()/staggerFromTo() calls were made.

At my age change is a shock to the system and I have to take out my rage and confusion on the neighbor kids by yelling at them to get off my lawn. :D

  • Haha 1
Link to comment
Share on other sites

11 minutes ago, PointC said:

At my age change is a shock to the system and I have to take out my rage and confusion on the neighbor kids by yelling at them to get off my lawn. :D

 

Those pesky whipper-snappers deserve it, no doubt. ;) 

  • Haha 1
Link to comment
Share on other sites

@GreenSock, @PointC - thanks for the insight guys! I reckon I've been "trained" by previous versions of GSAP that .set() calls at the start of a timeline should fire immediately, but programmatically, it does seem more consistent after the change. My new understanding - any operations involving rendering are executed at the next tick, but .pause() sets the internal timeline flag immediately. So in the scenario of timeline.set().pause(), by the time the next tick has rolled around, the timeline is already paused and nothing renders (this all assuming that immediateRender is not true). It'll take a few minors adjustments in my code, but nothing too bad. Appreciate the help, cheers!

  • Like 1
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.
×