Jump to content
GreenSock

trsh

addPause has strange effects on timeline animations

Recommended Posts

 

If I remove addPause line, the animations end as they should. With it, for some reason red (stalled) block goes nuts :)

 

Could be that this is a bug? If I want to use addPause and modify red block in end of it's tween, how can I get around this?

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

Link to comment
Share on other sites

The "nuts" behavior at the end is happening since your using set() setting both x and left CSS properties in your onComplete. So that is what is causing that offset shift "nuts" your seeing. You are changing the initial left position which is zero (0) and setting it to 700px which changes the orientation of the transform x.

 

Animating or setting with position offsets especially after a transform has been set will cause janky animation since left and top will trigger constant re-layout in the browser and does not animate on a sub-pixel level. Animating with x and y will allow the browser to animate on a sub-pixel level and will not cause constant re-layouts. And x and y can take advantage of using hardware acceleration to get a much smoother animation

 

Check out this article by GreenSock's Jack on why x and y are better than left an top.

 

https://css-tricks.com/myth-busting-css-animations-vs-javascript/

 

But please standby while we look into this behavior with addPause(), Thanks!

 

:)

  • Like 1
Link to comment
Share on other sites

The "nuts" behavior at the end is happening since your using set() setting both x and left CSS properties in your onComplete. So that is what is causing that offset shift "nuts" your seeing. You are changing the initial left position which is zero (0) and setting it to 700px which changes the orientation of the transform x.

 

Animating or setting with position offsets especially after a transform has been set will cause janky animation since left and top will trigger constant re-layout in the browser and does not animate on a sub-pixel level. Animating with x and y will allow the browser to animate on a sub-pixel level and will not cause constant re-layouts. And x and y can take advantage of using hardware acceleration to get a much smoother animation

 

Check out this article by GreenSock's Jack on why x and y are better than left an top.

 

https://css-tricks.com/myth-busting-css-animations-vs-javascript/

 

But please standby while we look into this behavior with addPause(), Thanks!

 

:)

 

1) I actually do not animate anything using left or top. It's set in very end of red box animation. And it's intended that way.

2) Can I some-have change the order? First x (taking in account old left position), and then add left.

3) And more importantly - why is this working in the way I want, if I do not add pause?

Link to comment
Share on other sites

Hi trsh,

 

Thanks for the demo. You do a good job of reducing the issues and it is appreciated.

However, I would ask that you take a just a little extra time to make your code more easy to understand.

 

1: please explain exactly what you expect each element to do AND what is happening wrong. "the red block goes nuts" leaves us a bit confused about what the intended behavior is that has multiple nested animations and callbacks

 

 

2 Please try to name your tweens / vars / objects in a more descriptive manner. its impossible to easily grasp what .box is and what .box2 is or why tween3 is controlling box2. We have to dig all the way into the CSS to find that box is the red one. 5 more minutes of cleaning up could easily save us 20 minutes.

 

Here is your demo with a few simple name changes that will hopefully help others understand more quickly what is happening: http://codepen.io/GreenSock/pen/LRQPzz?editors=1011

 

My current assessment is that when the timeline resumes that the ending value x:700 is being re-applied even though the onComplete callback set() already set x:0. When the timeline resumes the red element (now pink) has x:700 and left:700. 

 

 

The reason for this is that when the timeline resumes it needs to re-render all its child tweens at the current time. When the timeline was paused at 3.42 seconds, x needed to be 700 because a child tween which ended at 3 seconds had x:700 in its vars. The timeline has no idea that you created a tween OUTSIDE the timeline (via the callback) that got in the way. The timeline only knows that at 3.42 seconds it needs to render the redTween's target the same as it was at 3 seconds.

 

The solution for this is to set overwrite:"all" on the set that happens in the callback.

 

Please see the fix here: http://codepen.io/GreenSock/pen/LRQPzz?editors=1011

 

If we determine this to be a bug or have another solution we will let you know.

  • Like 1
Link to comment
Share on other sites

1) Carl thanks for the remarks. Sure I can prepare my samples better and I understand you very well. Next time i'll do it!

 

2) I have seen this overwrite setting, yet I couldn't figure out from the documentation what it actually does. Like what doe's it mean to Overwrite a tween? Sure you know, but I can sit for hours - google and experiment with that to understand the point. Anyway it doe's not seem serve well in my case, as it kills of further tweens -> 

See the Pen KgQwPQ?editors=1011%C2%A0 by anon (@anon) on CodePen

Link to comment
Share on other sites

Yup, what you have done below is technically the exact same thing as using an onComplete callback. 

timeline.add(function(){
  TweenMax.set(".red", {
    x: 0,
    left: 700+'px',
    backgroundColor:"pink"
  });
}, 3.01);

The timeline has absolutely no way of knowing that the function you are calling via add() is manipulating properties of objects that it has animated.

 

However if you use a set() instead at the same time, that is how the timeline can accurately set and maintain those values:

 

timeline.set(".red", {
    x: 0,
    left: 700+'px',
    backgroundColor:"pink"
  }, 3.01);
 
  • Like 2
Link to comment
Share on other sites

Carl. Mkay. You last example seems to do THE thing. I will try to integrate in my project tomorrow. 

Anyway, I think, that modified behavior when using pauses will attract more confused GSAP users :)

Link to comment
Share on other sites

Cool.

 

Fwiw we are still considering if something can or needs to change. Got a bunch going on at the moment.

Link to comment
Share on other sites

  • 2 weeks later...

Sorry for being late for the party :)

 

I took a peek and I see why it'd seem a little confusing but from what I can tell, everything is working exactly as expected. Let me explain...

 

Like Carl said, the timeline has no idea what you intend to do inside of your onComplete callback - it just calls the function. You happen to be changing the x/left properties in there which is fine, but it isn't as if it then inserts those values into the timeline. When the playhead changes position in a timeline, it must make sure that all of its child tweens/animations are in the proper state. In your case, you've got a tween that animates x to 700. So when you resume() your timeline and the playhead starts moving again, it says "hey, tween, make sure you render at the end properly which means...x:700". If we didn't do that, the state in a timeline could get out-of-whack. 

 

When you overwrite:"all", it finds all of the other tweens of that same element and kills them. In your case, that means it'd find that x:700 tween and nuke it. Therefore, when the timeline starts moving again and renders its state, x won't get set to 700 because that tween was killed (overwritten). 

 

Make more sense now? 

 

If you have any suggestions for more intuitive behavior, I'm all ears. As far as I can tell,  everything is working properly. 

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