Definitely felt more janky than 45fps and the graph implies that too.

While I thought this was from extra values being in the future (resulting in long durations of 0 fps, as the docshell jumped into the future), which may contribute, we also calculate the mean by traditional sumOfValues/noOfValues, and due to how FPS is recorded, means we'll have many more values for a higher framerate, than we will for lower. ex: If we have 10 values within one second for 60fps, and 1 value within one second for 0 fps, our average is 54fps, even though half the time was spent in 60fps and the other half was 0fps.

So this calculates frames over duration, rather than what we had before. Here's a screenshot of the two methods; the left number in the console is with this patch, the right one before: http://i.imgur.com/mRZa4kS.png

Comment on attachment 8599517 [details] [diff] [review] 1158645-fps.patch Review of attachment 8599517 [details] [diff] [review]: ----------------------------------------------------------------- Much better! I'm ashamed of the old approach. Doesn't this break any tests? If not, we need a test.

Added tests