Add an FPS graph to the Timeline about profiler HOT 6 OPEN

I'm removing the available tag from here, as I don't feel this is well scoped enough to be immediately actionable. I think we need more research into what this looks like, and maybe for the timeline to stabilize a bit more in its implementation.

from profiler.

Here is an example profile where I really wanted FPS information:
https://perfht.ml/2ClU1wJ

I profiled two tabs of perf.html. The first with React 15, the second with React 16, and I was in the stack chart using the mouse wheel. I wanted to see if there was any better FPS between the two as I was scrolling. It's not immediately obvious.

from profiler.

I have a use-case as simple as "I have two profiles and would like to know the average fps of each". For this, I don't need a more detailed timeline, just a gross fps number.

However, a frame time histogram would also be great.

from profiler.

What's the difference between the marker information in the profile and the requestAnimationFrame loop in the content of a page? I assume the profile can access markers for this information. For some reason the devtools has a performance framerate actor that accumulates requestAnimationFrame timings manually... Although it might have something to do with displaying framerates as they happen. I haven't dug into that part as much yet. I know jsantell was mentioning that the framerates are unreliable in the devtools perf tool.

https://dxr.mozilla.org/mozilla-central/source/devtools/server/performance/framerate.js

from profiler.

Interesting, I did not know that the devtools were using requestAnimationFrame in the content in order to get refresh driver information. The problem with requestAnimationFrame is that it affects what you're measuring: it will cause the refresh driver to fire at the full rate.

If you just look at the marker information, then you only see the refresh ticks that would actually have occurred; the observations are unaffected by the act of observing.

However, you usually want to know both the rate at which you painted and also the rate at which you could have painted. The requestAnimationFrame approach gives you the latter piece of information. But, since we know how our event loop + refresh driver works in Gecko, we can also obtain that information using a different data source: the "responsiveness" numbers on the samples.

For example: If the responsiveness numbers of all samples in a range are lower than 16ms, then it means that no event had to wait for longer than 16ms during that time. Refresh driver ticks are run from regular events that also go through the event loop, so all required refresh driver ticks would also have happened within 16ms, and we would have reached a refresh driver tick frequency of 60Hz.

from profiler.

I'm going to tentatively label this to be included in the Timeline panel.

from profiler.