Jump to content
GreenSock

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

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

Recommended Posts

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 ..

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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. 

  • Like 2
Link to comment
Share on other sites

19 hours ago, Carl said:

cryptic code stew.

 

 

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

  • Like 1
  • Haha 2
Link to comment
Share on other sites

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 ..

Link to comment
Share on other sites

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!

  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. 

  • Like 1
Link to comment
Share on other sites

All clear now ! Thanks for the patience. 

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

Link to comment
Share on other sites

Ah, okay, that makes sense. 

 

Happy tweening!

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.
×