taking a forward-going or a reversing timeline to the respective end

[tagger]

I have a timeline which can either be going in a regular (forward) direction or be reversing (.reverse() )

I would like to be able to get the timeline to finish immediately. if it is forwarding - to the end, if it is reversing - to the start.

if it is going forward I have no problem to t.time(t.endTime()). if it is going backward, I can check if t.reverse() and set the time to 0, probably

But I am looking for an elegant solution ( without an if ) that will take the head to the planned end ..

[Carl]

You could set the progress() to the inverse of the current reversed() state which will be either true/false which can be read as 1/0

 

See the Pen BEaJxo?editors=0010 by GreenSock (@GreenSock) on CodePen

 

However, I feel that an easy to read condition is better than this type of cryptic code stew.

[GreenSock]

Yeah, that does seem a little odd because technically you'd be setting progress() to true or false instead of 0 or 1. What about something like:

 

tl.progress( tl.reversed() ? 0 : 1 );

 

Oh, and you definitely should NOT be using t.time(t.endTime()) as you mentioned in the original post because endTime() refers to the position on the PARENT timeline. 

[PointC]

19 hours ago, Carl said:

cryptic code stew.

 

 

mmm... cryptic code stew. Nothing better on a cold and rainy weekend. 

[tagger]

thanks for advises !

wouldnt such a solution be race-prone ?

what if the .reversed() condition returns a certain state but by the time the .progress() is called - the animation already finishes and so, in fact, it will be reversed again? I know the time is minimal, but in a repetitive animation it might happen with some unexpected consequences. Or am I missing something ?

It feels there should be something built-in, atomic, in the library for such things ..

[GreenSock]

No, that's not how JavaScript works - you don't need to worry about that "race condition" you described. It would grab the reversed state on the exact same "tick" as the progress() call, and feed it in immediately. It would be impossible for the timeline to advance further in the mean time. 

 

Happy tweening!

[tagger]

Thanks, Jack

I was playing a little with the suggestions and while it indeed works, i did stumble on something i realise i dont really understand about greensock : at one hand, it seems to be asynchronous - the .reverse() function is non-blocking. At the other hand, i noticed that if i busy-wait on some attribute of the animated svg right after .reverse() returns - the animation gets stuck. So on what context does greensock run ? That attribute gets a specific value at the end of animation by .set

 

thanks

[GreenSock]

I'm not sure what you mean by "if I busy-wait on some attribute...", but maybe it'll help if I just give a simplistic view of how GSAP works. Basically, animation boils down to updating properties over time (typically 60 times per second) which is what makes it look like things are moving/fading/whatever. Things update on each requestAnimationFrame. So on each "tick" (requestAnimationFrame), GSAP rips through all of the animations that are currently running and figures out where each playhead should be, and sets properties accordingly. Then the next tick fires and everything happens all over again. There's nothing asynchronous about it. After it updates all the properties necessary on that tick, the browser does its rendering/painting and that's what you see.

 

GSAP is fundamentally a very fast property-updater. 

 

If you reverse() a 1-second timeline that's at its end, it'll wait for the next tick, move the playhead and render accordingly...then the next tick happens, the playhead is positioned and the tweens set the various properties accordingly, etc. That'd happen roughly 60 times over the course of 1 second. 

 

Does that help?

[tagger]

Definitely helps ! 

Just one more question so i can really understand : there is the context (thread?) on which my javascript runs. On that context i trigger the animation and the triger function is returning immediately. So i guess it sends some signal to another context on which greensock engine runs, and those ‘ticks’ frames are happening there. Right ? And this is that ‘greensock’s’ context which eventually calls any callbacks supplied. Is my understanding correct ?

 So if i understand correctly there are three threads involved : one for my js, one for greensock engine and one on which the browser renders ?

And to gather in the previous answer, the greensocks’ thread is just a single thread and this is why when it is handling my .reversed() query - it will not handle animationFrames and this is why the race condition I asked about will not happen ?

 

thanks again for your time

[GreenSock]

No, all JavaScript that updates anything in the browser ALWAYS runs on the main thread. There's no special context or other thread on which GSAP runs. It sounds like you may be overcomplicating things in your head a bit  

 

Basically, here's the sequence:

1. Browser fires a requestAnimationFrame event which GSAP listens for.
2. All the JavaScript runs (on the main thread) including GSAP as well as your own JS...ALL JavaScript. GSAP does all its work (moves the virtual playhead, calculates all the properties and applies them)
3. The browser renders/paints things (with the new properties that GSAP set) to the screen. 
4. After about 16.7ms (60fps), the whole cycle repeats. 

There's no race condition in your scenario because everything happens in order. The JavaScript executes one line at a time. You don't have to worry about a bunch of different threads that are all competing/racing. 

[tagger]

All clear now ! Thanks for the patience. 

Being an embedded sw engineer originally, i am used to look for multiple contexts

[GreenSock]

Ah, okay, that makes sense. 

 

Happy tweening!