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)

defect

Tracking

(blocking-b2g:koi+, b2g-v1.2 fixed)

RESOLVED FIXED
1.2 C3(Oct25)
blocking-b2g koi+
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
Severity: normal → blocker
blocking-b2g: --- → koi?
Depends on: 914900
Priority: -- → P1
Severity: blocker → critical
blocking-b2g: koi? → koi+
Keywords: perf
Whiteboard: [c=handeye p= s= u=1.2]
Whiteboard: [c=handeye p= s= u=1.2] → [c=handeye p= s= u=1.2]
Blocks: 915064
Per Sandip on bug 914900: Minimum Expected Benchmark for Contacts App Scrolling is 57 FPS.
Assignee: nobody → bkelly
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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)
Attaching contacts.
Flags: needinfo?(mvikram)
Attached file local.zip (deleted) —
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.
Also, with the improvements in the FPS, we still see significant stutters while scrolling.
See https://bugzilla.mozilla.org/show_bug.cgi?id=915120#c6 - we're still working on something that could explain this.
Currently, rotated buffers are not rendered via HWC. Will this change allow it to be rendered by HWC?
Also, won't this improve scroll performance in general, across other apps as well?
(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.
(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.
(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 :)
Depends on: 925348
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.
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
Target Milestone: --- → 1.2 C3(Oct25)
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.
Depends on: 921212
No longer depends on: 918179
Whiteboard: [c=handeye p= s= u=1.2] → [c=handeye p=5 s= u=1.2]
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: