Jump to content

Guest GRDC

Dynamic Destination Values Failing with Lag (updateTo, startAt, onStart

Moderator Tag
Go to solution Solved by Guest GRDC,

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 am fairly new to GSAP, and am very pleased with its capabilities.  My question is:


I wish to animate the timeline twice, the first time at a timeScale of 100 (instantaneous), and then once at normal speed.  I am capturing the positions of the objects the first time to draw SVG paths so that the user may interact with the underlying tweens graphically.  Many of the elements depend the relative positioning of other elements on the screen which are dynamic.  I am using the updateTo() method in the startAt parameter to determine the destination values at the time the tween starts, which also updates the tween's duration (and eventually other values).


My problem is, that the timeline works fine when it is run at a very slow timeScale.  When the timeScale is increased to 100, the calculation of the dynamic destinations appears to cause some lag, and the players are not returned to their original positions (seemingly because of the tweens not being executed synchronously).


I have tried to invalidate values before the calculation, which has helped some.  My next option is to pause the main timeline when it is evident that the tween's destination values are dynamic in the startAt parameter.


Another issue I've encountered is that updating a tween's duration does not update the duration of the timeline it resides on, causing the object to pause briefly before moving on to its next tween.  If I update a tween's duration, will it be reflected in the timelines above?  I could perform a recalculation once the timeScale(100) timeline has finished drawing before allowing the user to play the timeline themselves.


Thanks for any advice on these subjects in advance.

Link to comment
Share on other sites

Hi and welcome to the GreenSock forums. 


I don't follow everything exactly, it would really help to see a very simplified example of what you are trying to do.


Another issue I've encountered is that updating a tween's duration does not update the duration of the timeline it resides on


I can't seem to replicate this. Changing the duration() of a child tween certainly should change the duration() of its parent timeline.

Here is a basic example

var tl = new TimelineLite()

var tween1 = TweenLite.to("#redBox", 1, {x:550})

  .to("#blueBox", 1, {x:550})

console.log("initial tl.duration() = " + tl.duration()) // 2 seconds
console.log("make tween1 duration(6)")
console.log("tl.duration() after making tween1 6 seconds long =  " + tl.duration()) // 6 seconds



Its important to note that changing the duration of the first tween does NOT move the second tween. The second tween's startTime() will remain unchanged at 1.


Let us know if you need more clarification. We will be able to comment on the other parts once we can see what it is you are doing with timeScale(100).

  • Like 2
Link to comment
Share on other sites

Thank you for the prompt response Carl.  At present, the timline is generating 10 layers of nested tweens, so providing a simple codepen to demonstrate may be difficult.  Here are some debugging results.


Your comment on changing a tween's duration makes total sense.  Is there a way to automatically adjust the duration/offset parent timelines to reflect when a tween's duration is changed?  For now, if a tween's duration is adjusted to be more than its initial state (using upudatetTo in onStart while the timeline is running), a subsequent tween hijacks the movements of the tween in question, as it has not yet finished.


As for the lag, I've been trying to set up the initial run through the timeline at timeScale(100) to not allow for any lag, as many of the calculations that are made while the timeline is running the first time are based on the previous/end positions of the actors.  What settings would I want if I wanted to accept zero when a timeline plays?  Something like lagSmoothing(1,1)?


Thanks again!

Link to comment
Share on other sites

For no lagSmoothing use TweenLite.lagSmoothing(0)


Is there a way to automatically adjust the duration/offset parent timelines to reflect when a tween's duration is changed?


I'm not quite sure I'm reading that properly, as we just agreed that changing a tweens duration() will affect the parent's duration(). If you want to move future tweens out of the way of the current tween you just made longer you can use shiftChildren()


It seems to me like you are creating a timeline that you are largely overwriting as soon as its made. Obviously I don't know a lot about your project but I almost feel like you could either


A) destroy it completely and rebuild it whenever you need to play it OR B) just build it as its playing. 


From what I'm reading it seems like you are building it the first time with a bunch of values you don't want just to update them immediately.



--- EDIT ---


Ok, i just re-read your first post, and I see now that you are doing this largely to create SVG paths that follow whatever is being tweened.

Take a look at this CodePen demo: http://codepen.io/GreenSock/pen/ABkdL


Notice it places a bunch of DOM dots along a bezierPath. Its not SVG, but perhaps the same theory can apply, as it is technically playing very fast to pre-calculate the position of each dot... but its not playing.


Instead of setting timeScale(SuperHighValue), we are using a loop to slightly increment the time() value repeatedly. So in essence the calculations and placement of the DOM dots is happening instantly, but it won't break if the external calculations you are making can't keep up at the rate of which the timeline is playing.

  • Like 1
Link to comment
Share on other sites

  • Solution

That worked wonderfully.  What is the difference between incrementing the progress by .001 or animating the timeline instantaneously?  I'm guessing that timeline.resume() causes things to become asynchronous.


Anyway, the build-once method through iteration did the trick.



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.