Closed
Bug 937350
Opened 11 years ago
Closed 11 years ago
[1.2] Regression in Settings App Scroll FPS (compared to an earlier 1.2 build)
Categories
(Firefox OS Graveyard :: Gaia::Settings, defect, P1)
Tracking
(blocking-b2g:koi+)
People
(Reporter: mvikram, Assigned: kgrandon)
References
Details
(Keywords: perf, regression, Whiteboard: [c=handeye p= s= u=1.2])
Attachments
(1 file)
141.31 KB,
image/jpeg
|
Details |
While measuring FPS on the following build with a high speed camera, it was measured to be 44 fps. Gecko: 964f7c844f2793092bab72612d5da2f5bcfd6c2e Gaia: be4ea00a50236b10eb0a03232a28ffd0048e0cb8 On the earlier build,the FPS was measured to be 57 fps (as a result, bug 896821 was closed): Gaia version: 845801e0c74badf0b96657a864935ef1a983cf47 Gecko version: bbb4c0a8fa65cf1546a6cedc4c20fea16cd63ef On profiling this, here are some observations: - it seems like frames are taking on the average 24-28 ms with some taking 35-40 ms. - CompositorOGL->Begin Frame() to layerManagerComposite->EndFrame() Or Compositor->Composite usually takes 8-12 ms with a few taking 12-14 ms Will attach snapshot.
Reporter | ||
Updated•11 years ago
|
Severity: normal → blocker
blocking-b2g: --- → koi?
OS: Windows 7 → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Reporter | ||
Comment 1•11 years ago
|
||
Comment 2•11 years ago
|
||
Kevin, Arthur, do you aware of any changes between these builds?
Flags: needinfo?(kgrandon)
Flags: needinfo?(arthur.chen)
Assignee | ||
Comment 3•11 years ago
|
||
Looks to be an ~18 day regression window? I can't think of anything off the top of my head. Possibly something in the platform if multiple apps regressed? I'll keep my eye on the other scroll bugs and try to run a profile as well.
Flags: needinfo?(kgrandon)
Comment 4•11 years ago
|
||
I can't think of critical changes related to scrolling performance either. One thing worth to note is that there are tiny rendering changes related to checkbox between 11/5 and 11/6 builds. On 11/5 build, when quick tapping on a check box, the displaying result seems not synced with the actual state.
Flags: needinfo?(arthur.chen)
Reporter | ||
Comment 5•11 years ago
|
||
The scroll fps measured on the following build was 54 fps: Gecko: d5ccbecb3abd3c760dcef7b5f7195cbeea667cc1 Gaia: 2ef9bc3c7a6de228b63e6ba3613eb0c0dd639c59
Assignee | ||
Comment 6•11 years ago
|
||
I'll start looking at this, but anyone else can feel free to do investigation or make fixes here. Thanks!
Assignee: nobody → kgrandon
Status: NEW → ASSIGNED
Updated•11 years ago
|
blocking-b2g: koi? → koi+
Updated•11 years ago
|
Priority: -- → P1
Whiteboard: [c=handeye p= s= u=] → [c=handeye p= s= u=1.2]
Target Milestone: --- → 1.2 C5(Nov22)
Reporter | ||
Comment 7•11 years ago
|
||
New measurements on the following build using a high speed camera show a result of 51 fps: Gecko: 8926376583fdd3711aaf75594fd4084306c5f02a Gaia: 3cc5e6ddec0656b3a6a197e989dabebee536c982
Comment 8•11 years ago
|
||
Bug 938785 should increase the overall performance but it's not the cause of the regression. It should be a simple CSS change so I don't see why we shouldn't take it as well.
Depends on: 938785
Updated•11 years ago
|
Keywords: regression
Comment 9•11 years ago
|
||
Can we re-run these tests with bug 938785 resolved to verify this remains a blocker? I'm assuming that if we get the framerate above 50 and it's no longer discernible, we'll call it a day here. Otherwise, Kevin will hopefully be able to look at this after bug 937714.
Flags: needinfo?(mvikram)
Comment 10•11 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #9) > Can we re-run these tests with bug 938785 resolved to verify this remains a > blocker? I'm assuming that if we get the framerate above 50 and it's no > longer discernible, we'll call it a day here. Alex, so far we have not been able to reproduce this regression. I have been using settings to investigate any root cause over in bug 936535, so a lot of my data is over there. You can see from the "Counter Chart" in this spreadsheet, though, that we ramp up to 60fps in the first ~450ms of the scroll and exceed 50fps after ~350ms: https://docs.google.com/spreadsheet/ccc?key=0Ai4XIgrcTvUQdDFWTTk3NWw3Y2pyanoxS3p2X1ZJSVE&usp=sharing This ramp up behavior is the same as it was previously in v1.2. So we can make optimizations and try to measure an improvement, but so far we have not been able to reproduce the 20% to 30% reported regression. This means we might have difficulty determining when we are "good enough".
Comment 11•11 years ago
|
||
Vikram, can we close this bug based on bug 936535 comment 60 and our phone call? It sounds like more recent tests show that setting fps is no longer problematic.
Reporter | ||
Comment 12•11 years ago
|
||
On the following build, the scroll FPS measured using the high speed camera was 54 fps: Gecko: 14432474328e7558902329c3fc2a8238c3222a7f Gaia: 7a23f8c53ba97da9c63a7275b36d155b4526a639 This is within the expected range. We can close this bug.
Flags: needinfo?(mvikram)
Comment 13•11 years ago
|
||
Resolving WFM based on comment 12.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•