Closed
Bug 706309
Opened 13 years ago
Closed 13 years ago
Possible Tp4m-nochrome regression
Categories
(Firefox for Android Graveyard :: General, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mbrubeck, Assigned: mbrubeck)
References
Details
(Keywords: perf, regression)
Attachments
(1 file)
|
(deleted),
patch
|
Details | Diff | Splinter Review |
Tp appears to have regressed on birch sometime on 11/28 or 11/29. Noise in the data makes it hard to pin down an exact changeset where the regression occurred:
http://graphs-new.mozilla.org/graph.html#tests=[[84,27,20]]&sel=none&displayrange=7&datatype=running
This might be caused by the viewport code from bug 694901 changing the browser size more often than necessary.
|
Assignee | |
Comment 1•13 years ago
|
||
This patch adds some timestamp logging to the viewport code; it doesn't identify any noticeably expensive operations during page load.
An alternate theory is that we recently fixed bugs that caused us to paint only part of the page; now that we are painting the whole page, rendering might be more expensive.
|
|
Assignee | |
Comment 2•13 years ago
|
||
After running some more Tp4m benchmarks on the surrounding changesets, it's clear this is a regression from bug 694901.
|
||
Comment 3•13 years ago
|
||
Matt, this is a P2 for you to make a call whether this can be fixed or we can live with the regression
Priority: -- → P2
|
|
||
Updated•13 years ago
|
tracking-fennec: --- → 11+
|
|
Assignee | |
Comment 4•13 years ago
|
||
This seems to have been caused by an increase in the number of redraws and size changes, which was fixed by work like bug 709492.
|
|
Assignee | |
Updated•13 years ago
|
tracking-fennec: 11+ → ---
|
||
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•