Closed
Bug 915118
Opened 11 years ago
Closed 11 years ago
[1.2] Regression in Contacts Scroll FPS (compared to [1.1])
Categories
(Firefox OS Graveyard :: Gaia::Contacts, defect, P1)
Firefox OS Graveyard
Gaia::Contacts
Tracking
(blocking-b2g:koi+, b2g-v1.2 fixed)
Tracking | Status | |
---|---|---|
b2g-v1.2 | --- | fixed |
People
(Reporter: mvikram, Assigned: bkelly)
References
Details
(Keywords: perf, Whiteboard: [c=handeye p=5 s= u=1.2] )
Attachments
(1 file)
(deleted),
application/x-zip-compressed
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36
Steps to reproduce:
Based on high speed camera measurements (on a QRD 7x27 device), there seems to be a degradation in UX scroll performance of the Contacts App.
Actual results:
Measurements on 1.2:
40 FPS
Measurements on 1.1:
60 FPS
Reporter | ||
Updated•11 years ago
|
Updated•11 years ago
|
Severity: blocker → critical
blocking-b2g: koi? → koi+
Updated•11 years ago
|
Whiteboard: [c=handeye p= s= u=1.2] → [c=handeye p= s= u=1.2]
Comment 2•11 years ago
|
||
Per Sandip on bug 914900: Minimum Expected Benchmark for Contacts App Scrolling is 57 FPS.
Updated•11 years ago
|
Assignee: nobody → bkelly
Assignee | ||
Updated•11 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 3•11 years ago
|
||
Can you indicate how many contacts your test was performed with? Also, do they have contact images? Is scrolling being performed immediately after the first page of contacts appears?
Just want to make sure I test the same conditions. Thanks!
Flags: needinfo?(mvikram)
Reporter | ||
Comment 5•11 years ago
|
||
Assignee | ||
Comment 6•11 years ago
|
||
Updated test measurement with 1.2 revs:
Gecko: f98470e4c52dbcd3ee0236d7566df733b89f9fa9
Gaia: c932c482c6944fa32724ce7af9e5423c4c2bcccd
Results in 57 fps. This is a nice improvement over 40 fps previously measured and just shy of the 60 fps measured with v1.1.
I'd like to investigate if the tag_visibility_monitor is causing any of the degradation here.
Reporter | ||
Comment 7•11 years ago
|
||
Also, with the improvements in the FPS, we still see significant stutters while scrolling.
Comment 8•11 years ago
|
||
See https://bugzilla.mozilla.org/show_bug.cgi?id=915120#c6 - we're still working on something that could explain this.
Reporter | ||
Comment 9•11 years ago
|
||
Currently, rotated buffers are not rendered via HWC. Will this change allow it to be rendered by HWC?
Reporter | ||
Comment 10•11 years ago
|
||
Also, won't this improve scroll performance in general, across other apps as well?
Assignee | ||
Comment 11•11 years ago
|
||
(In reply to Mandyam Vikram from comment #7)
> Also, with the improvements in the FPS, we still see significant stutters
> while scrolling.
Thank you! I had missed that piece of information previously.
(In reply to Milan Sreckovic [:milan] from comment #8)
> See https://bugzilla.mozilla.org/show_bug.cgi?id=915120#c6 - we're still
> working on something that could explain this.
I don't know if its significant, but I believe that contacts switches in and out of buffer rotation due to the way it uses CSS translateY() to keep the group header fixed at the top of the page. At least this was our thought when originally looking at bug 881970.
Comment 12•11 years ago
|
||
(In reply to Mandyam Vikram from comment #9)
> Currently, rotated buffers are not rendered via HWC. Will this change allow
> it to be rendered by HWC?
This doesn't change when we have rotated buffers and when we perform the "unrotate", so there should be no change there. I did not realize that we don't use HWC when we have rotated buffers. We were discussing dispensing with buffer rotation completely, this is good information to have.
Comment 13•11 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #12)
> (In reply to Mandyam Vikram from comment #9)
> > Currently, rotated buffers are not rendered via HWC. Will this change allow
> > it to be rendered by HWC?
>
> This doesn't change when we have rotated buffers and when we perform the
> "unrotate", so there should be no change there. I did not realize that we
> don't use HWC when we have rotated buffers. We were discussing dispensing
> with buffer rotation completely, this is good information to have.
Just to be clear "I" didn't realize the above - others on the graphics team new :)
Assignee | ||
Comment 14•11 years ago
|
||
There are two different cases to test here:
1) After initial load where the majority of the contacts have not been rendered. In this case we must render while scrolling.
2) After the contacts have been rendered. In this case there should be less work to do, but there are still some scroll handlers firing and some work occurring.
Initial profiling case (1) shows our rendering during scroll is taking too long. See dependent bug 925348.
Assignee | ||
Comment 15•11 years ago
|
||
The pull request seems to help case (1) from comment 14 fairly well. For case (2) I think we need to fix bug 918179 before we can assess other possible fixes.
Depends on: 918179
Updated•11 years ago
|
Target Milestone: --- → 1.2 C3(Oct25)
Assignee | ||
Comment 16•11 years ago
|
||
So it occurs to me I am really focused on scrolling jank now and not pure fps numbers. Based on that I am going to put new information in bug 922316 instead of here.
I'm leaving this open as bug 921212 is still be worked on which should hopefully get us back up to 60fps.
Assignee | ||
Updated•11 years ago
|
Whiteboard: [c=handeye p= s= u=1.2] → [c=handeye p=5 s= u=1.2]
Assignee | ||
Comment 17•11 years ago
|
||
Per latest partner reports, contacts app is now scrolling at 60 fps and no longer regresses against v1.1. Therefore I'm closing this bug as fixed. Scroll jank issues will be worked in bug 922316.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
status-b2g-v1.2:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•