Add an FPS graph to the Timeline

[mstange]

The marker timeline and the jank markers already let you see when we painted and how long that took, and whether the thread was available for painting at all or busy doing something else (janking). But a line graph of the FPS might be a more useful visualization in some cases, especially if you're looking at a long running profile and are not zoomed in enough to care about individual paints.

We could have a line graph that displays both theoretical max FPS (based on the "responsiveness" information from the profile samples) and actual FPS, overlaid on top of each other. Maybe we should put both the content process and the parent process into the same graph. The parent process usually manages a higher theoretical FPS than the content process, so if we pick the right drawing order and the right colors (+ fill or no fill), it might not look too overwhelming.

┆Issue is synchronized with this Jira Task

[gregtatum]

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

[mstange]

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.

[gregtatum]

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

[gregtatum]

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.

[gregtatum]

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.

[kdashg]

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.