andytwoods

Gsap timelinelite oncomplete - upon screen refresh?

Recommended Posts

Hi,
Would 'onComplete'/'onStart' wait to fire upon 'screen refresh'? If not, how can I achieve this?
Thanks, Andy.

 

edit: So I explored this via code. Find below results (asking for block to appear for 100ms). Results imply  'onComplete'/'onStart' do fire upon screen refresh/new frame. Must say, the results make me nervous.  Fingers crossed there is a bug in my code.

Here is a codeOpen exploration. 

 

stat_descriptor  av  stdev  min  max
start_dur  16.420999999999886  2.655742111278148  7.490000000000009  39.90499999999997
end_dur  93.43405000000013  8.488287613743891  63.65499999999997  101.95000000000073

 

start_dur, or 'time the code was started' makes sense. It's one refresh, after the item was asked to be placed on screen. 

 

edit2: approx 40 ms between max and min durations. Thats approx 2 refreshes. What you'd expect? 

Share this post


Link to post
Share on other sites

I thought to repeat the above exploration but when using frames (codeopen).

 

stat_descriptor  av  stdev  min  max
start_dur  16.798700000000064  3.8474303125724116  15.13000000000011  54.35000000000002
end_dur  83.65744999999997  1.3122920220019905  78.39999999999964  87.49999999999909

Share this post


Link to post
Share on other sites

I read your question a few times and I'm not quite sure what you're asking, but let me clarify a few things:

  1. By default, GSAP is driven by a single requestAnimationFrame loop, thus all of its refreshes are tied to that. You can set TweenLite.ticker.useRAF(false) if you prefer using setTimeout(), but I would discourage that since animation should almost always be tied to screen refreshes.
  2. "onStart" fires on the first render of the tween. And a tween doesn't render when you create it (unless immediateRender:true is set). It'd be wasteful to render immediately in most cases because there's no change yet. For example, if obj.x is 0 and you tween it to() 100, rendering it at time:0 would be utterly wasteful because it's already at that value. Thus, on the very next requestAnimationFrame is when it'd render for the first time and the onStart() would fire. So please account for this in your calculations. In other words, don't assume that onStart() gets called literally at a time of 0; it's when things render for the first time (typically one tick into the tween...when values start changing).
  3. The browser is in complete control of the timing of requestAnimationFrame. If you're on a screen that has a 30hz refresh rate, it'll have more time between refreshes than a 60hz one. And if there's a lot of work being done on the main thread, it can sometimes delay the calling of requestAnimationFrame. That's all very normal. 
  4. Yes, all callbacks (onStart, onComplete, etc.) are tied to the central ticker, thus by default it'll be tied to requestAnimationFrame events (screen refreshes). Again, that's a good thing :)
  5. The way you're doing your loop() is inaccurate; it allows time gaps to creep in. For example, let's say you've got a 1000ms tween but the browser dispatches a rAF at 998ms and then at 1014ms; the onComplete would fire at 1014ms (correctly), but you're adding a new tween to the timeline so that it's arranged immediately after that tween that just completed, thus technically it's already 14ms deep. Its onStart would fire on the very next tick which will likely be about 16.7ms later, so at that point it's now 21ms deep (though it may be more if the browser is busy or if your screen refresh rate is lower). You could, of course, set immediateRender:true if you need that. 

Does that clear things up at all? 

  • Like 1

Share this post


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.