Thought this was fixed, but looks like that's not the case! Chenxia recorded a profile from a nightly fennec (on device, of an `about:*` page) yesterday and the FPS graph is suspiciously flat, reporting a 120+ average FPS. (Also if you haven't seen a recording from fennec device, check it out, frame pseudostacks are a bit different)

last file was corrupted, here we go

This gets close. We also have duration differences in the last recorded tick and total duration of the profile. I suspect this'll be cleaned out once there's a real performance actor, but this fixes the > 60FPS issues.

Comment on attachment 8635547 [details] [diff] [review] 1171489-max-fps.patch Review of attachment 8635547 [details] [diff] [review]: ----------------------------------------------------------------- I don't think this is an appropriate fix. We should find out *why* that number gets so high, not just blindingly clamp it.

Comment on attachment 8635547 [details] [diff] [review] 1171489-max-fps.patch Muscle memory made me r+ when I wanted to r-

Look at the attached json -- the ticks timestamps: "1446.665648000002","1496.5664580000011","1496.9937430000027" ,"1497.146345000001","1503.1588580000025","1503.341980000001","1503.5251020000032","1690.7370670000018","1690.9 201890000004","1691.042271000002","1742.0112920000029","1742.1333730000042","1742.2249340000053","1788.18861600 0003","1788.3106970000008","1788.402258000002","1799.9999990000033","1800.1220810000013","1800.2136420000024"," 1820.1434450000052","1820.2655259999992","1820.3570880000007","1833.297725000004" It's very possible to have ticks faster than ~16ms resulting in > 60FPS with request animation frame. Is there some perspective I don't understand?

And how this is calculated is duration divided by # of frames (ticks.length), so it's pretty straight forward how we can get > 60 FPS -- I think this can be further improved once the end times are in sync (right now the ticks stop recording with some extra room in the profiler (probably should just assume 60 FPS at any discrepency in end times)

This occurs when having a document with an iframe, and refreshing, causes us to count multiple docshells. Got a fix, just need a test.

I think this fixes it for real. The tests seem wonky, got any better ideas? If we can get this in for Fx42 on Monday that'd be awesome

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #7) > This occurs when having a document with an iframe, and refreshing, causes us > to count multiple docshells. Got a fix, just need a test. Knew it! Reviewing.

Made the test more flexible, firing up the mochitest other tests again: https://treeherder.mozilla.org/#/jobs?repo=try&revision=05ff683f4893