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)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:koi+)

RESOLVED WORKSFORME
1.2 C5(Nov22)
blocking-b2g koi+

People

(Reporter: mvikram, Assigned: kgrandon)

References

Details

(Keywords: perf, regression, Whiteboard: [c=handeye p= s= u=1.2])

Attachments

(1 file)

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.
Severity: normal → blocker
blocking-b2g: --- → koi?
OS: Windows 7 → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Attached image settings.jpg
Depends on: 937375
Keywords: perf
Whiteboard: [c=handeye p= s= u=]
Kevin, Arthur, do you aware of any changes between these builds?
Flags: needinfo?(kgrandon)
Flags: needinfo?(arthur.chen)
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)
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)
The scroll fps measured on the following build was 54 fps:
Gecko:
d5ccbecb3abd3c760dcef7b5f7195cbeea667cc1
Gaia:
2ef9bc3c7a6de228b63e6ba3613eb0c0dd639c59
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
blocking-b2g: koi? → koi+
Priority: -- → P1
Whiteboard: [c=handeye p= s= u=] → [c=handeye p= s= u=1.2]
Target Milestone: --- → 1.2 C5(Nov22)
New measurements on the following build using a high speed camera show a result of 51 fps:
Gecko:
8926376583fdd3711aaf75594fd4084306c5f02a
Gaia:
3cc5e6ddec0656b3a6a197e989dabebee536c982
No longer depends on: 937375
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
Keywords: regression
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)
(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".
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.
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)
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.

Attachment

General

Creator:
Created:
Updated:
Size: