Closed Bug 915078 Opened 11 years ago Closed 11 years ago

[1.2] Gallery App launch time has regressed (compared to [1.1]

Categories

(Firefox OS Graveyard :: Gaia::Gallery, defect, P1)

All
Gonk (Firefox OS)
defect

Tracking

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

RESOLVED FIXED
blocking-b2g koi+
Tracking Status
b2g-v1.2 --- fixed

People

(Reporter: mvikram, Assigned: jhylands)

References

Details

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

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:

Launch the Gallery App (QRD 7x27 device). Measurements are made using a high speed camera measuring the time from when the touch event was recognized to first app paint.



Actual results:

Measured time on (1.2) is:
3363ms
Measured time on (1.1):
1146 ms
Depends on: 914903
OS: All → Gonk (Firefox OS)
Priority: -- → P1
blocking-b2g: --- → koi+
I used this patch http://people.mozilla.com/~jmuizelaar/genlock-logging-patch to profile it, 

For gallery launch, we are spending 1000+987 = 1987ms in Android::GraphicBuffer::lock() function. It causes two very long paints (1000ms and 987ms) during startup of Gallery.

Looks like B2G Compositor thread has held the lock and Gallery app is unable to take the lock again in ShadowLayerForwarder::OpenDescriptor() .

It causes two long paints during Gallery startup. 

Please note that I launched gallery 10 times and I have seen this problem 8 times.
Keywords: perf, regression
Whiteboard: [c=progress p= s= u=1.2]
Whiteboard: [c=progress p= s= u=1.2] → [c=progress p= s= u=1.2]
Blocks: 915068
Assignee: nobody → jhylands
Waiting for input from Tapas on bug 906715 to unblock this
Per Qualcomm's report, first launch latency has improved from 3363 ms to 1129 ms, which is slightly faster than 1.1, so I am closing this bug as fixed.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.