Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Sahil

seek and suppressEvents odd behavior

Recommended Posts

 

While trying to answer this thread I thought maybe suppressing events and callbacks will work but I came across this odd behavior. In example I am using seek with suppressEvents parameter, whether it is set to true or false, the pause function gets called. But if I set suppressEvents to false, the timeline doesn't stay paused while if it is set to true, the timeline stays paused.

 

@GreenSock @Carl Can you explain what is going on in this example below?

 

See the Pen PEqKQj by Sahil89 (@Sahil89) on CodePen

Link to post
Share on other sites

Hey Sahil,

 

Thanks for the super clean demo. Very helpful.

 

I'm pretty sure (and @GreenSock can confirm or deny) that suppressEvents:true only suppresses events that you jump over, like those that are between where the playhead is now and where you are seeking to.

 

In your example your call() is at the same exact time as the "middle" label, so you are landing exactly where the call() is and when the playhead exits the "middle" frame it needs to call your pause function.

 

Try the following test:

 

tl.seek("middle+=0.0001",true).play();

 

This will seek a teensy eensy little bit past the middle frame, thus passing the call() and suppressing it.

If you change the value to false, you will see your console.log() fire.

 

Hopefully that helps (and is correct :-D)

 

 

 

 

 

 

  • Like 2
Link to post
Share on other sites

Thanks Carl, I kind of guessed from yesterday's question. But actually I am curious about why setting it to false plays the timeline? I mean what is even relationship of suppressEvents  false here?

Link to post
Share on other sites

Ah, ok, I see. You are wondering why the timeline resumes playing even though you log out that tl.paused() is true.

 

My guess is that the play() that is tacked onto the end is being called after your function runs.

 

tl.seek("middle", false).play();
  1. seek to middle
  2. pause function gets called
  3. tl.play() happens

I'll call in air support ( @GreenSock ) once again ;)

 

 

  • Like 1
Link to post
Share on other sites

Ohk we will go in circle here but I read it few times and I still have same question so just forgive me for being curious. :-D

 

but then why does it not behave same when suppressEvents is true? I can guess that there might be some logic in place that causes whatever few milliseconds execution delay that causes the play to be called slightly before pause. Just guessing though, please confirm.

Link to post
Share on other sites

I don't blame you for being a bit confused by the behavior. Let me explain...

 

There are actually two ways in which a callback can be triggered - when the playhead enters or when it exits a position on the timeline. Obviously it shouldn't do both (duplicate calls). This is critical for zero-duration tweens and callbacks like this. If you suppressEvents when seeking to a new spot, it indeed suppresses the events while moving there, but if it lands EXACTLY on top of a zero-duration tween or callback, that will (and should) be called when the playhead exits that position. This is actually a very important and purposeful we implemented based on a lot of feedback in the past. 

 

So in your demo, the seek() gets called and suppresses events (thus it doesn't call the function that pauses things). It immediately calls play() at that point (the moment the seek() is done executing, thus it's still on the same "tick"). Then, on the very next tick, the playhead leaves that position and it says "oh, there's a callback that wasn't triggered when the playhead arrived there, so we'll fire it now as it exits". 

 

Does that clear things up? 

 

If you toggle suppressEvents back to false, then the order of things gets switched around - the pause function gets called INSIDE that seek() call...then play() is called, thus it continues playing after that. 

  • Like 2
  • Thanks 1
Link to post
Share on other sites

Thanks Jack, it makes perfect sense now.

Link to post
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.

×