Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Jonathan Scott

Resume of staggered timeline causes element to disappear

Recommended Posts

My slider (see Codepen) has elements sliding in turn from left to right, with the previous slide fading out as the new one slides over. It works fine except when I pause it while the first slide is moving (the red box in the Codepen): if I then resume it the first slide immediately disappears. Resuming when the other boxes are moving works fine too. I guess one of the autoAlpha:0 properties is being applied in a way that I don't understand, but I would be grateful for any help with understanding why that's happening and how to fix.

See the Pen ZyVxpe by anon (@anon) on CodePen

Link to comment
Share on other sites

First of all, welcome to the forums. 

 

I noticed 2 problems:

  1. You put the immediateRender:false in the wrong place (it belongs in the "to" vars, not the "from" vars). 
  2. The bigger problem, though, is that you've got autoAlpha defined in the "from" but not the "to" which means that tween will only set that value initially but during the course of the tween it will NOT control that value at all. Keep in mind that you also have a tween earlier in the timeline that fully controls that autoAlpha value. Thus, when you resume(), the timeline must render its full state at that point (in case you changed any values outside the timeline), so the earlier tween renders at its final state (autoAlpha:0) and the later tween renders at its current state (doesn't alter autoAlpha because you didn't tell it to actually control that value - there wasn't anything in the "to" portion of the tween for that value), so it stays 0. 

The solution is to to place autoAlpha:1 in the "to" portion of the tween as well. Or if your goal is to set that autoAlpha value at that particular spot in the timeline, use a set() instead of a tween where you're partially tweening things and partially setting things. Like this: 

See the Pen 9d137059e0c08ba3b10da89650aff1a7 by GreenSock (@GreenSock) on CodePen

 

Does that clear things up? 

  • Like 2
Link to comment
Share on other sites

Thanks for the reply. I have moved the immediateRender to the 'to' properties (seems strange, my understanding of immediateRender is that it applies to the 'from' properties but it does seem to work either way).

I set autoAlpha to 1 in the staggerFromTo 'from' properties to ensure that a previously faded box would be fully visible before the slide started.  I don't want that Tween to then change the autoAlpha, the autoAlpha has to change in the following Tween (after the slide has moved left), hence it's in the staggerTo and the to of the Tweens that act on the box that precedes the sliding one in the sequence.

I can see your solution works - thank you - but in my understanding a 'set' at that point in the timeline is exactly the same as a 'from' with immediateRender = false. So in your solution, at that point in the timeline the autoAlpha is set to 0, and in my original, the 'from' properties of the fromTo set autoAlpha to 0 at exactly the same point and so the resume should work the same in both cases. If you have time to explain what's wrong with my thinking then that would be useful for future reference, if not then I will just gratefully accept your working solution!

Link to comment
Share on other sites

It's not really that you're "wrong" for thinking that way - I can see why it'd be a bit confusing. 

 

The whole idea of a fromTo() or staggerFromTo() is to let you define BOTH the starting AND ending values of a tween (like "tween x from 0 to 100"). But you're trying to use the "from" as a state-setting mechanism that's disconnected from the tween (like "tween x from 0 to....um...I'm not telling you anything about the end value."). I think that's where the confusion is.

 

It isn't as if those "from" values keep getting set over the course of the entire tween. Those are only used to initially set the values right before things get recorded internally for the tweening start/end states. The "to" values dictate the properties that are recorded internally and applied over the course of the tween. The assumption is that any "from" value will also have a "to" value. 

 

That's why the set() call is most appropriate here - it's a very clear state-setting mechanism at a particular spot in time. 

 

Does that clear things up? 

Link to comment
Share on other sites

Yes I see where my misunderstanding was now, thank you very much for your time.

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