understanding chrome timeline re: fps

[erikb]

If I run and record a timeline in chrome 38 for my sample project, the timeline is a little confusing to me.

 

In what appears to be one frame (in "frames" mode), multiple firings of "Animation Frame Fired" take place.  The timeline tool also reports the FPS here is 20!  Is this a bug with chrome's timeline tool?  It looks like someone else has asked a similar question.

 

See the Pen uBylg by jedierikb (@jedierikb) on CodePen

[erikb]

This simple modification (just extending animation durations)

See the Pen yiImD by jedierikb (@jedierikb) on CodePen

shows the FPS slowdown in the chrome fps meter. Dropping to 12fps?! Something's not right; this doesn't seem accurate.  The animation looks smooth!

[Rodrigo]

HI Erik,

 

I believe you're reading this info in a wrong way. In terms of Chrome the lower the bar size the better. In this case it means most of the paints in your app are taking small amounts of time, good enough to be over 60 fps.

 

Take a look at this video by Paul Irish, is pretty neat and instructive to get a better grasp of how Chrome's tools work, how you can  get the most out of them and what's coming in the future to make devs lives a little easier:

 

[erikb]

Thanks Rodrigo.  That is a useful video, and indeed my fps is generally excellent in the bar graph along the top of the timeline tools.

 

But what to make of multiple RAF events being fired in 'one frame' (wherein 'one frame' is selected by clicking the rectangle I have bracketed in red)?  Down below the fps is recorded as 20fps in the 'frame statistics' tab.

 

 

 

And what to make in the drop in fps in the example I posted?  Note the precipitous drop to 17fps in the screenshot posted:

 

[GreenSock]

As far as I can tell, GSAP is performing great. Keep in mind:

1. The browser is in charge of dispatching requestAnimationFrame events. If they're firing in an unexpected way (which frankly I have never heard of), that would be a Chrome/browser issue. 
2. Every authority I've talked to about FPS meters tells me that none of them are truly accurate. Lots of reasons (I won't bore you with an explanation now)
3. Chrome is known for being very slow at resizing images. So for example, if you have a 1000x500 image that you show at 200x100, there's a relatively heavy performance hit. Again, that has nothing to do with GSAP. 
4. When I looked at your codepen even with Dev Tools open, it easily ran at 60fps with plenty of room to spare. If you focus on a FPS counter that's saying it is running at 20fps, there's almost surely something wrong with the meter, not GSAP. If I were in your shoes, I'd focus most of my attention on actual performance rather than the [likely flawed] FPS counter in Dev Tools. 
5. You might want to ask the Chrome team about these questions since it looks to me like they'd be in the best position to get you answers. As far as I can tell, I don't think this is pointing to any problems with GSAP specifically, but let me know if you see evidence to the contrary. 

[erikb]

Apparent performance for this demo is just fine.  Greensock continues to perform admirably par excellence.  

 

I am trying to debug performance issues wherein greensock is one component and chasing this issue down led to the strange findings reported in my post.  Given your expertise in performance tuning with your library, I thought the graphs might make sense to you.

 

I will inquire with the chromium team.

[erikb]

This helpful response regarding chromium internals may be of interest to the greensock developer community:

https://groups.google.com/forum/#!topic/google-chrome-developer-tools/S_mKrF42a4Y

[Jonathan]

Hello erikb,

 

Make sure when testing performance or paints in Chrome or Firefox, to use a Incognito Mode Window or Tab. Google Dev Team states to use Incognito Mode since not using it can end up skewing your results.

 

Just my two cents

[GreenSock]

Hm, I read that Google response and it's not really adding up to me - it sounds like he's under the impression that you're doing CSS animations of transforms. As far as I know...

1. ALL JavaScript runs in the main thread (well, except maybe Web Workers, but that's different). GSAP is JavaScript, so every update is made on the main thread. This is actually a good thing in many ways (despite what you may read elsewhere) because it ensures perfect synchronization. 
2. Some browsers spin CSS animations of transforms and opacity off to another thread and give it direct access to the compositor so it's possible that those transforms would be painted to the screen much more often than whatever's on the main thread (JS). In other words, JS might be chugging at 5fps while the compositor paints CSS animations of transforms to the screen at 20fps. I believe that's what he was trying to describe, where they have to somehow meld those numbers into a single FPS value. 
3. Since all updates are on the main thread with GSAP, the dynamic he's describing couldn't happen, where you're seeing things painted to the screen more often than the main thread is chugging along. In your case, everything is on the main thread anyway. There shouldn't be any disparity. 
4. I have seen some very, VERY strange behavior in Chrome's Dev Tools and the way it reports performance stuff in the timeline. Like...clearly problems in Dev Tools itself. Carl and I stumbled across something in the last 24 hours that was quite surprising in fact. So don't put too much faith in the data it's giving you. Don't get me wrong - I LOVE Dev Tools and it's incredibly useful. But it has some warts.