seek and suppressEvents odd behavior

[Sahil 2,627 Likes (Superhero)]

 

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

[Carl 9,887 Likes (Superhero)]

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 )

 

 

 

 

 

 

[GreenSock 13,314 Likes (Superhero)]

Yep, Carl is exactly right.

[Sahil 2,627 Likes (Superhero)]

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?

[Carl 9,887 Likes (Superhero)]

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

 

 

[GreenSock 13,314 Likes (Superhero)]

Exactamundo. 

[Sahil 2,627 Likes (Superhero)]

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. 

 

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.

[GreenSock 13,314 Likes (Superhero)]

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. 

[Sahil 2,627 Likes (Superhero)]

Thanks Jack, it makes perfect sense now.