Closed Bug 906715 Opened 7 years ago Closed 6 years ago
gralloc unlock and UI lagginess
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().
Nothing but "feeling", but it seems I can somehow state the same for Nexus S, too.
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.
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() .
(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?
Woo nice to see activity on this bug. So lock() issues would explain the performance regression between 1.1 and 1.2 ?
(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.
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 .
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.
> 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.
Tapas - are you comfortable with having this bug resolved now?
(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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.