Jump to content
Search Community

How to seek back to the position 0 with render?

RolandSoos test
Moderator Tag

Go to solution Solved by RolandSoos,

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

I have attached a Codepen with a special case. This is just taken out from a complex system and I'm unable to use different "use case" for the Tween creation.

 

I have an element and I know that the target X value for this element is 0. I have an algorithm which creates the fromTo tweens for the preceding tweens and also a simple Tween with duration 0 to set the calculated "starting" value. (this 0 duration is a hack to position the element to the right place on play(0), because of the first fromTo has a delay and it won't render until the delay ended).

 

So the question is, how could I add these tweens to the timeline and the set the timeline's position to 0, which would mean x: 500 in my example?

 

Also it seems like on my Codepen example, that the duration 0 tween isn't work fine with the latest version. I'm using VERSION: 1.11.8 and it works fine there. It could be great if you could give a better solution for that hack.

 

Thank you!

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

Link to comment
Share on other sites

Hi and thanks for the CodePen demo.

 

Please let me know if this works for you

 

var tl = new TimelineLite({
  paused: true
})

tl.fromTo("#redBox", 2, {x:500}, {x: 200}, 1.5);
tl.fromTo("#redBox", 2, {x:200}, {x: 0, immediateRender:false});

 

http://codepen.io/GreenSock/pen/Iwdqz?editors=001

 

The starting position of x:500 will be rendered immediately (before the delay transpires).

If you later choose to pause(0), play(0), or restart() the box will always start at x:500

 

I think the main issue you were facing was that fromTo() tweens have their immediateRender property set to true by default. 

This is expected / convenient behavior 99% of the time. It causes trouble though when you have multiple fromTo() tweens controlling the same properties of the same object.

In your case, your second fromTo()'s render cycle was causing a conflict with the first fromTo() — both were fighting to set the x position of #redBox

 

 

 

note:

tl.fromTo("#redBox", 2, {x:500}, {x: 200}, 1.5);
// same as
tl.fromTo("#redBox", 2, {x:500}, {x: 200, delay:1.5});

Using delay is fine, but I think you will find the position parameter to give you far more control: http://greensock.com/position-parameter

  • Like 4
Link to comment
Share on other sites

Thanks you are right. I have redefined my animations a little bit. (I haven't followed everything you wrote, but I have followed your directions in my solution.)

 

So I have changed the algorithm in my animatons, removed the 0 duration hack and instead used .fromTo only for the first animation and other animations on the same element only use .to

 

But I bumped into my real original problem, which I haven't yet described here.

 

I just create the specified timeline, then I have to set back the element to the original position (currently x:0). The I need to pause it on the 0 position, but with this step the element should immediately jump to the x:500 position. Then a play should start the whole animation and end on x:0.

 

use cases

 

#1

Load codepen

Hit Zero button - this jumps back the element to x:0

Hit pause(0) button - now the timeline should render the element on x:500, but it does nothing

hit play button - the animation should play from x:500, but it just waits the delay and just then jumps to x:500

 

 

#2

Load codepen

Hit Zero button - this jumps back the element to x:0

hit play button - the animation should play from x:500, but it just waits the delay and just then jumps to x:500

 

 

New codepen:

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

 

I hope you can help me out on this one too!

Link to comment
Share on other sites

Thanks again for the demo and the clear explanation of the use cases.

 

The problem is that when you force x:0 with this tween

TweenLite.set('#redBox', {x: 0});

The timeline has no knowledge whatsoever that this happened. It already rendered at time(0) with x:500 and as far as it knows it only needs to worry about animating (or rendering) the x property once the 1.5 second delay transpires. 

 

It doesn't know you are going behind its back moving things around that you already told to it to control. 

 

The only way the system could be smart enough to keep its eyes on external changes would be to double-check the value of every property before every animation starts. This would add a huge performance penalty across the entire engine. 

 

A solution for your problem is to find a way to force the timeline to re-render which can can be done by setting progress(1) immediately before the play() or pause() like so:

 

$("#pause").on("click", function() {
  tl.progress(1).pause(0);
});


$("#play").on("click", function() {
  tl.progress(1).play(0);
});
 
 
Again, your problem is that the timeline knows it already rendered at time(0), so here you are moving the playhead forward and back to force a new render.
 
I believe this solution works for both use cases
  • 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.
×
×
  • Create New...