Jump to content
Search Community

Two calls to seek produce different results

softevo test
Moderator Tag

Go to solution Solved by GreenSock,

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 ran into a problem that I can understand. Would be great if someone can explain the behavior my Codepen shows.


The code contains two calls to seek(...). The first to point to 0.4 seconds and the second to go to 0.3 seconds.


If I delete the first (seek(0.4)), the box is displayed at left=0px as expected.


If I first call seek(0.4) and then seek(0.3) the box will be displayed at left=100px. That is the start value of the tween so I thought that a call to seek(0.3) should always produce the left=0px start value.


Can someone please help me with this?


Best regards


See the Pen bqpjdo by ozerfrettelter (@ozerfrettelter) on CodePen

Link to comment
Share on other sites

You've got a 0.4 position set on the tween relative to its timeline ... so nothing *should* happen before 0.4


The timeline is playing, but the tween will not kick in until 0.4 ... so seeing 0.3 should show that it hasn't begun.



[EDIT] I completely misread the issue ... sorry, disregard my comment :)

Link to comment
Share on other sites

That is strange. I'm curious about the reason this is happening too.


I'm assuming it has something to do with the playhead moving to the exact start of that tween at 0.4.


I did notice if you put any other seek time in there it works fine. Even a tiny change to 0.401 and it works. If it's exactly 0.4, it will still seek forward and will seek back to 0, but if you try to seek between 0 and 0.4, it seems to stay at 0.4.  :blink:  

  • Like 1
Link to comment
Share on other sites

Hi PointC,


Yes, that's something I also found out. Sadly in my case it will be the user who moves the playhead so I can't go with any cheap workaround :(


With whatever UI you are using to let them control the playhead, you could always add .001 to the calculated value ... maybe?


I can't imagine the user has control to the 1000ths.

Link to comment
Share on other sites

Usually I'm the first to find a quick workaround. But in this case I'm sure that it will introduce a lot of trouble in the long run. 


With my prev post I wanted to drive away the discussion from workarounds ;-) 

Link to comment
Share on other sites

  • 2 weeks later...
  • Solution

Sorry about that. I believe I found the issue and the ONLY time you'd run into it is if you have a fromTo() tween with immediateRender:false and you put the playhead directly on top of the starting time and THEN somewhere before it (very rare). One of the optimizations we make internally is to skip rendering in cases when the requested render time is identical to the the current time that's reflected. In other words, if a tween renders at a time of 0 and then later it's asked to render at a time of 0, it should be like "hey, I'm already at 0...I don't need to do anything, so I won't chew up CPU cycles needlessly".


In this particular scenario, you've got it rendering at a time of 0 exactly, and then when you move the playhead backwards, technically the tween is still being asked to render at 0 (you can't have a negative time) - that's why it skipped that render. But the "from" part needed to revert in your case. It's a tricky scenario because fromTo() tweens with immediateRender:false have 3 unique states - the "from", the "to" and the "before from" part. :)


I've added some code to the next release that should resolve that particular scenario. You can preview it (uncompressed) at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js


To be clear, it would have worked if you put the playhead anywhere else except directly on top of the start time, like seek(0.401) instead of seek(0.4) in your example. 


Sorry about any confusion there. Thanks for letting us know about it. 

  • Like 4
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...