Runtime benchmark index, to check if device can handle it

[bfred.it]

How can I test the performance of the visitor's device on page load? So that if it does <20 FPS I can skip animations altogether

 

I didn't find anything like this in the documentation

[Rodrigo]

Hi,

 

Once I had in mind creating a fps to check how the created animations were working, for many resons I didn't even started but the few things that I had in mind was using the requestAnimationFrame method.

 

One thing that you could use is the ticker property of the engine (api reference) in order to check how many times the engine is updating. To read more detailed info about it check the following posts:

 

http://forums.greensock.com/topic/7598-overwritemanager-oncomplete-bug/?hl=ticker#entry28827

 

http://forums.greensock.com/topic/7499-animations-lag-when-chrome-has-multiple-tabs-open/?hl=ticker#entry28753

 

Jack explains with a little more detail how the ticker property works under the hood and maybe this can help you getting started.

 

Hope this helps,

Cheers,

Rodrigo.

[Carl]

Hi Federico,

 

Welcome to the GreenSock forums.

 

I saw you tweet about this issue, thanks so much for posting it here. Twitter's character limit makes it pretty difficult to communicate about technical issues. 

 

Right now we don't provide stress tests, but I can give you some tips on what you can do. 

First there are a few things to keep in mind. 

 

All the calculations that GSAP performs are highly optimized and run extremely fast. It would be very uncommon that any JavaScript execution taking place inside the engine would cause an issue with your site. 99.99% of the performance issues you may encounter with GSAP will be due to browser rendering performance. 

 

In short, GSAP is just running some math to change numeric values over time. Most likely those values are being applied to css properties. When the browser needs to repaint / render the updates, that is where the heavy lifting takes place. Browsers vary greatly in their ability to quickly and repeatedly redraw the DOM. 

 

That being said, the only way to stress test a device is create an animation, wait for it to play, and then figure out how long it took. Whatever test you create the end user will have to see. Keep in mind that in order to create a decent stress test, you are going to have to create a test that is well, reasonably stressful, and by its very nature won't look good on a number of older devices.

 

Do you really want the first thing your mobile users see be a poor looking animation?

Sure, chances are most animations are going to run VERY well on iOS and modern Android devices, but the type of animation you have in mind may be too much for older hardware. 

 

You can use some properties of TweenLite.ticker to get an accurate sampling of fps.

ticker.time is the current time in seconds

ticker.frame is the number of the current frame

 

View the codepen demo here

See the Pen e95ae74f13bb1a9c9eb3c4734f18e113 by GreenSock (@GreenSock) on CodePen

 

 

Notice after the animation runs you see how long the animation took and the fps.

 

You can uncomment the line of code that has 

//.call(alert, ["wait a little bit"], window)

to simulate a processor hangup as JavaScript execution will halt when an alert() fires.