Jump to content
Search Community

TimeLineLite timing accuracy (usable in behavioural reaction time based research?)

andytwoods test
Moderator Tag

Go to solution Solved by GreenSock,

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Dear all,

 

how accurate is TimeLineLite?

 

People advise to stick with setTimeOut() for accurate timing of visual elements on screen (http://link.springer.com/article/10.3758/s13428-016-0783-4, the actual pdf) and not to use external packages (which presumably would add bulk/unknown-inaccuracies).

 

I see that you can measure timing in TimeLineLite in terms of ticks. This seems the ultimate way of controlling for timing. But are onscreen happenings guaranteed to stick to ticks?

 

I've been using Greensock for years and would be so happy to use it again :)

 

cheers,

Andy.

 

Edit: v relevant prev post here. Advises following setting to avoid inaccuracies: TweenLite.lagSmoothing(0)

Link to comment
Share on other sites

Hi andytwoods,

 

As with everything in the world, the answer will probably be: it depends.

 

Firstly, I'm not speaking for GSAP in any official capacity - just as an individual.

 

Looking at your links I see they are vey technical and scientific - Not a criticism, just laying out what I see your point of view being.

 

I have a question: Are you asking how accurate the tick is in terms of scientifically accurate to a real-world tick (1/60 of a second)?

 

Going back to the "it depends": It depends on what application you are targeting your animation.

 

For game development and online interaction the tick is extremely accurate. For some physics it's also quite accurate. For calculations on how atoms would move in the first second of the Big Bang, it would probably be not so accurate. 

 

The biggest thing to consider here is the browser, because it is the browser, plus the machine that's running the browser, that will dictate how many ticks will happen in a given second. Depending on the circumstances the browser will throttle RaF down to conserve energy, sometimes it will drop a tick because it missed the 16 milliseconds window to render all it needed. The RaF will do everything in its power to guarantee a smooth animation playback but it will still be constrained by the browser.

 

I do believe GSAP is extremely performant and will stick to the ticks so, every calculation will be performed, but whether the browser is going to render the image on every tick will be a completely different story as the rendering is not controlled by GSAP.

 

If you are doing scientific simulations, you will need to isolate all variables - as you probably know - before you can start considering if the visual elements are being displayed on the screen. The hardware it is running on, what software it is running on, then the amount of pixels/points you are trying to render on the screen.

 

My personal position would be: you will have a guaranteed rendering of all pixels you require if you have a combination and control of a hardware/software that is powerful enough to handle it. If you are trying to guarantee the image is going to render flawlessly out on the wild west of the internet, I am afraid there is no guarantee that you will not be losing a frame here or there or a dozen.

  • Like 1
Link to comment
Share on other sites

Many thanks @Dipscom,

 

my question boils down to:

 

is timelinelite as accurate as setTimeOut() ?

(both ways would be susceptible to the same plethora of issues that affect browser based timing).

 

At the moment, I've style.visibility = 'hidden' and then just set that to style.visiblilty = ''visible" when needed.

 

I guess, worse comes to worse, I could measure timing via hardware like my chum Thomas Schubert (with an arduino and a photodiode). But it would be awesome to avoid this step.

 

Cheers,
Andy.

Link to comment
Share on other sites

By no means take my answer for the official one ;)

 

I'd say yes because GSAP uses RaF and defaults to setTimeOut when not available (or told to use).

 

http://greensock.com/docs/#/HTML5/GSAP/TweenLite/ticker/

 

I'd say it's as accurate as one might hope it to be. Mr. Greensock here is very keen on performance and he makes sure GSAP as as little "fat" on as possible. 

 

Once again, it will boil down to what is your intended use. If you are going to be using it for cognitive response of the brain, I'd set a couple of tests to check the accuracy versus the technique your chum uses. :P

  • Like 1
Link to comment
Share on other sites

Thanks for the question.

 

I'm actually surprised setTimeout was recommended for accuracy, my experience has always been that people strongly urge not to rely on it:

 

http://stackoverflow.com/questions/21097421/what-is-the-reason-javascript-settimeout-is-so-inaccurate

http://stackoverflow.com/questions/196027/is-there-a-more-accurate-way-to-create-a-javascript-timer-than-settimeout

 

GSAP takes timing very seriously, which is why it does not use setTimeout. By using raf GSAP not only has its "heartbeat" tick at consistent intervals BUT every time a render occurs GSAP takes into account the amount of time that has passed since all of its animations have started and renders them all the way they should appear at that time. This means that everything inside of GSAP is always absolutely, 100% synchronized.

 

I can tell GSAP to start an animation that is 3 hours long and then tell another animation to have a 3 hour delay and the second one will always start at the exact moment the first one ended.

 

Definitely read this article about lagSmoothing() to learn more about timing concerns inside of GSAP: http://greensock.com/gsap-1-12-0

 

The only thing that GSAP can not control is render speed. So if you tell 10,000 elements to change their width it may take additional time for the browser to recalculate the layout and render those changes to the screen. GSAP will always fire its instructions with accuracy but rendering speed is a potential bottle-neck.

  • Like 2
Link to comment
Share on other sites

  • Solution

Yep, Carl is exactly right. To add a few more details...

 

setTimeout() doesn't concern itself with rendering cycles in the browser, thus it can theoretically get called BETWEEN renders (not synchronized with screen refreshes). This is yet another reason we avoid it by default - it's completely wasteful to have an animation engine do its calculations inbetween screen renders. For example, let's say you do a setTimeout() that fires every 4ms, but the screen only refreshes every 16.67ms...It'd be silly for GSAP to run all its calculations 3 times inbetween screen refreshes (you'd never see any of those inbetween states). 

 

Also, setTimeout() is horribly inaccurate when the browser tab is hidden. Depending on the browser, it can delay things up to 2 full seconds I believe. This is done in the name of "optimization". rAF is also delayed, of course (as it should be). 

 

And like Carl said, GSAP is time-based, not tick-based in terms of calculating animation state. It's only tick-based in terms of when its renders are triggered. Well, there is a useFrames:true option you can use if you WANT the timing to be tick-based, but that's quite uncommon.

 

Does that clarify things adequately for you?  

  • Like 1
Link to comment
Share on other sites

Thanks all. That's really awesome!

 

I chatted with Thomas Schubert and we're thinking of repeating his 2013 study but with RequestAnimationFrame based software. Maybe Josh de Leeuw will be interested too (JsPsyc, that popular online psychology package). Important that people know how the tech has changed. 

 

You guys want to get involved? Drop me an email :)

 

cheers,
Andy.

 

PS we did a simulation here regarding that 'over frames' issue you mentioned and it really is scary bananas how impactful it can be:

fig-5-2x.jpg

Link to comment
Share on other sites

Nice one, thanks.

 

Will try to persuade my company to sponsor this research. Would be cool for it to be opensource/openaccess and perhaps cover a research assistant's fees for a few weeks. Also a nice little headline perhaps (we intend to use GSAP in v3 of Xperiment). Might try for $500? Fingers crossed. 

 

Would be cool if you could try too.

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.
×
×
  • Create New...