FPS reporting still inaccurate

RESOLVED FIXED in Firefox 42

Status

defect
RESOLVED FIXED
4 years ago
11 months ago

People

(Reporter: jsantell, Assigned: jsantell)

Tracking

41 Branch
Firefox 42
Dependency tree / graph

Firefox Tracking Flags

(firefox41 affected, firefox42 fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

Posted file android-profile-liuche.json (obsolete) —
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
Attachment #8615349 - Attachment is obsolete: true
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.
Assignee: nobody → jsantell
Status: NEW → ASSIGNED
Attachment #8635547 - Flags: review?(vporof)
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.
Attachment #8635547 - Flags: review?(vporof) → review+
Comment on attachment 8635547 [details] [diff] [review]
1171489-max-fps.patch

Muscle memory made me r+ when I wanted to r-
Attachment #8635547 - Flags: review+ → review-
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)
Blocks: perf-tools-fx43
No longer blocks: perf-tools-fx42
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
Attachment #8645279 - Flags: review?(vporof)
(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.
Attachment #8645279 - Flags: review?(vporof) → review+
Blocks: perf-tools-fx42
No longer blocks: perf-tools-fx43
Blocks: perf-tools-fx43
No longer blocks: perf-tools-fx42
Blocks: perf-tools-fx42
No longer blocks: perf-tools-fx43
Made the test more flexible, firing up the mochitest other tests again: https://treeherder.mozilla.org/#/jobs?repo=try&revision=05ff683f4893
https://hg.mozilla.org/mozilla-central/rev/f750fa33440a
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 42

Updated

11 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.