Closed
Bug 1146237
Opened 10 years ago
Closed 10 years ago
FPS drops to 0 when opening an app
Categories
(DevTools :: Performance Tools (Profiler/Timeline), defect, P1)
Tracking
(firefox40 fixed, firefox41 fixed)
RESOLVED
FIXED
Firefox 41
People
(Reporter: paul, Assigned: jsantell)
References
Details
Attachments
(3 files, 1 obsolete file)
37.63 KB,
image/png
|
Details | |
9.48 MB,
application/json
|
Details | |
2.33 KB,
patch
|
jsantell
:
review+
Sylvestre
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
When profiling the main process, the FPS graph drops to 0. Stays at 0 even if I close the app.
Updated•10 years ago
|
Blocks: perf-tool-v2
Comment 1•10 years ago
|
||
Apparently this isn't only affecting FxOS
Summary: FxOS / Perf++: FPS drops to 0 when opening an app → FPS drops to 0 when opening an app
Assignee | ||
Updated•10 years ago
|
Priority: -- → P1
Assignee | ||
Comment 2•10 years ago
|
||
I've had this happen before as well, but not sure how to consistently recreate it. Any ideas?
Assignee | ||
Comment 3•10 years ago
|
||
got a recording of it. the frames data from the actor has about 680 values, and is a 15s recording. Inspecting the data there...
> json.ticks[200]
'3351.9978289999963'
> json.ticks[210]
'3519.1548000000003'
> json.ticks[211]
'3535.1599760000026'
> json.ticks[212]
'3552.061393'
> json.ticks[213]
'3568.217128999997'
> json.ticks[214]
'3596.334998999999'
> json.ticks[215]
'4347.913415999992'
> json.ticks[216]
'38827.078467'
> json.ticks[217]
'38827.13419699999'
> json.ticks[218]
'73939.084618'
So somewhere around there, it jumps from timestamps of 3s, to 4s, to 38s and then 73s, with the end of the array being at 83s.
Assignee | ||
Comment 4•10 years ago
|
||
I suspect this is why the average is skewed in bug 1158645, as all those values in the future are being counted, just not displayed.
Blocks: 1158645
Comment 5•10 years ago
|
||
Need to wait for bug 1152829 and a unified way of measuring time, so we don't rely on performance.now() anymore.
Assignee: nobody → vporof
Updated•10 years ago
|
Status: NEW → ASSIGNED
Comment 7•10 years ago
|
||
Making bug 1152829 as see-also, since I'm not entirely sure this issue is caused because of our reliance on performance.now(). I'll investigate it anyway in the meantime.
Assignee | ||
Comment 8•10 years ago
|
||
So this uses docShell.now(), which is what timeline actor uses.
The docShells getter is lifted right from the timeline actor. And that looks very similar to what the tab actor has in the first place. We should consolidate these somehow, AND if we only care about the main window for these, then cache the docshell we are interested in, because that can take up 1-2% in costs from what I can tell (just accessing TabActor's originalDocShell).
I don't know all the details with the docshell stuff though, so won't be able to get any nice refactoring in for this in time for 40.1, but hopefully this prevents flat lining.
Assignee: vporof → jsantell
Attachment #8610862 -
Flags: review?(vporof)
Assignee | ||
Comment 9•10 years ago
|
||
Comment 10•10 years ago
|
||
Comment on attachment 8610862 [details] [diff] [review]
1146237-framerate-actor.patch
Review of attachment 8610862 [details] [diff] [review]:
-----------------------------------------------------------------
::: toolkit/devtools/server/actors/framerate.js
@@ +127,5 @@
> + let docShell = docShellsEnum.getNext();
> + docShells.push(docShell.QueryInterface(Ci.nsIDocShell));
> + }
> +
> + return docShells;
Why return all the docshells instead of just the first one?
Attachment #8610862 -
Flags: review?(vporof) → review+
Assignee | ||
Comment 11•10 years ago
|
||
(In reply to Victor Porof [:vporof][:vp] from comment #10)
> Comment on attachment 8610862 [details] [diff] [review]
> 1146237-framerate-actor.patch
>
> Review of attachment 8610862 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> ::: toolkit/devtools/server/actors/framerate.js
> @@ +127,5 @@
> > + let docShell = docShellsEnum.getNext();
> > + docShells.push(docShell.QueryInterface(Ci.nsIDocShell));
> > + }
> > +
> > + return docShells;
>
> Why return all the docshells instead of just the first one?
Ah, timeline does that for markers on iframes, just no paint markers on those iframes, I misunderstood that. OK I can clean up this getter then in that case
Assignee | ||
Comment 12•10 years ago
|
||
Just use tabActor.docShell.
Attachment #8610862 -
Attachment is obsolete: true
Attachment #8611449 -
Flags: review+
Assignee | ||
Comment 13•10 years ago
|
||
Blocks: perf-40-uplifts
Whiteboard: [fixed-in-fx-team]
Comment 15•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-firefox41:
--- → fixed
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 41
Comment 16•10 years ago
|
||
Comment on attachment 8611449 [details] [diff] [review]
1146237-framerate-actor.patch
Approval Request Comment
[Feature/regressing bug #]: 1167252, the new performance tool
[User impact if declined]: The performance tool framerate will be wrong when reloading a page
[Describe test coverage new/current, TreeHerder]: There are try pushes in Bug 1167252
[Risks and why]: Minor - the risk is contained within devtools performance panel.
[String/UUID change made/needed]: None
Attachment #8611449 -
Flags: approval-mozilla-aurora?
Updated•10 years ago
|
Attachment #8611449 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 17•10 years ago
|
||
status-firefox40:
--- → fixed
Updated•7 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•