906715 - gralloc unlock and UI lagginess

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[:gerard-majax]

While bisecting a bug on Inari, I've ran into some lagginess of the UI. From a user point of view, it's like some frames are missing/dropped.

I can't provide precise adb logcat for now, but this happened with pvtbuilds of gecko central for inari around 15-22th of july.

When the hiccups happens, it could be more or less linked to genlock/gralloc errors reporting -EINVAL on unlock().

Comment 1

[:gerard-majax]

Nothing but "feeling", but it seems I can somehow state the same for Nexus S, too.

Comment 2

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

i also see same issue for Gallery App launch. We are spending almost 416+1000+987 = 2403ms in Android::GraphicBuffer::lock() function during Gallery App launch.

This is causing major launch latency regression in gallery app.

Comment 3

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

This patch http://people.mozilla.com/~jmuizelaar/genlock-logging-patch can be used to see Paint delay during Gallery app launch because of GraphicBuffer::Lock() .

Comment 4

[Jeff Muizelaar [:jrmuizel]]

(In reply to Tapas Kumar Kundu from comment #3)
> This patch http://people.mozilla.com/~jmuizelaar/genlock-logging-patch can
> be used to see Paint delay during Gallery app launch because of
> GraphicBuffer::Lock() .

Can you get a full stack for the Lock() that is taking a long time?

Comment 5

[:gerard-majax]

Woo nice to see activity on this bug. So lock() issues would explain the performance regression between 1.1 and 1.2 ?

Comment 6

[Jeff Muizelaar [:jrmuizel]]

(In reply to Alexandre LISSY :gerard-majax (off 26/08-08/09) from comment #5)
> Woo nice to see activity on this bug. So lock() issues would explain the
> performance regression between 1.1 and 1.2 ?

Not necessarily. The best thing to do would be to get a profile of startup. Then we can see if the long Lock() calls are the problem.

Comment 7

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: stack trace for 1st time launc of gallery app.

This is stack trace for 1st time launc of gallery app. We series of paint during startup of gallery which takes beyond >500ms and sometime 1sec. Cause of this very long paint delay is gralloc lock failure. 

It cab be reproduced in following way:
1) Apply http://people.mozilla.org/~jmuizelaar/genlock-logging-patch and build & flash boot, system and userdata.
2) Load gallery 1st time. 
3) see in |adb logcat -v threadtime| for genlock time taken and which pid has taken time.

This problem also happens again if you quit gallery app and launch it again. This time we see 2 very big PresShell::Paint() delay (each of Paint() is ~1sec)

lock() is happening inside RenderLayer() during GPU Composition. Compositor thread is creating READ lock for gralloc buffer without releasing it and APP does not see stutter as long as it tries to get READ lock of same gralloc buffer. But if APP tries to get WRITE lock of same gralloc buffer then it is sees big 1sec Paint() delay .

Comment 8

[Mandyam Vikram]

Please refer https://bugzilla.mozilla.org/show_bug.cgi?id=916264

>> +++ This bug was initially created as a clone of Bug #912134 +++
.....
>> There is a similar bug of Bug 906715. But I keep this bus as separate from the bug. Bug 906715 comment 
>> 0 has a following comment. It is about a bug of unlock(). And do not see this error since Bug 912134
>> fixed.

The fix for Bug 912134 addressing the genlock issues above should be verified now that the patch has landed.

Comment 9

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

> Created attachment 804170 [details]
> stack trace for 1st time launc of gallery app.
> 
> This is stack trace for 1st time launc of gallery app. We series of paint
> during startup of gallery which takes beyond >500ms and sometime 1sec. Cause
> of this very long paint delay is gralloc lock failure. 
> 

I am not seeing this problem anymore for Gallery launch.

Comment 10

[Jon Hylands [:jhylands]]

Tapas - are you comfortable with having this bug resolved now?

Comment 11

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Jon Hylands [:jhylands] from comment #10)
> Tapas - are you comfortable with having this bug resolved now?

Yes. I don't think that it is required now.

Comment 12

[Jon Hylands [:jhylands]]

Closing.