1015413 - Gallery scroll shows black screen and tile rendering issues.

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Sushil]

Steps:
1) Open Gallery.
2) Make sure it has at-least 60 photos.
3) Now do Gallery scroll.

During scroll, black screen and grey tiles (in place of thumbnails) are observed. The issue is observed even after disabling HWC. So it looks to be rendering side issue since FrameBuffer is the only layer present in frame during GPU Composition. It seems the acquire fence of FB layer is not considering waiting on the content of each thumbnail present in frame.

Comment 1

[Sushil]

Sotaro, is it a known issue on v1.4 ?

Comment 2

[Sotaro Ikeda [:sotaro]]

It might be Bug 1006957.

Comment 3

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #2)
> It might be Bug 1006957.

But it could be different. Anyway, it seems very similar issue.

Comment 4

[Preeti Raghunath(:Preeti)]

Please include video of the bug.

Comment 5

[Jason Smith [:jsmith]]

Without a video, we do not have an understanding of the impact here, which means we can't block on this. Please renominate if the video is provided.

Comment 6

[bhargavg1]

(In reply to Jason Smith [:jsmith] from comment #5)
> Without a video, we do not have an understanding of the impact here, which
> means we can't block on this. Please renominate if the video is provided.

Video shared at, https://drive.google.com/file/d/0B0zTAnPOpx-xbk5uRWdSWDUyOUE/edit?usp=sharing

Bringing back 1.4? please check if status needs to be updated

Comment 7

[Preeti Raghunath(:Preeti)]

The video displays rather bad UX and hence blocking.

QA,

Please check on Flame device.

Comment 8

[Joshua Mitchell (Inactive)]

Issue does NOT repro on 1.4 Flame
Environmental Variables:
Device: Flame 1.4
Build ID: 20140604100718
Gaia: 1f238df7ac68a73a4ceb27391a204c800f38ab1c
Gecko: a7b7f1b579cc
Version: 30.0 (1.4) 
Firmware Version: v10G-2

Issue does NOT reproduce on 2.0 Flame
Environmental Variables:
Device: Flame 2.0
Build ID: 20140605061016
Gaia: 908f94fda04462001ece86e6b6c15ad8b05f7526
Gecko: 219b3ed1b996
Version: 32.0a1 (2.0) 
Firmware Version: v10G-2

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

Sushil, this is QRD?  Sotaro, do we have one of those?

Comment 10

[Sotaro Ikeda [:sotaro]]

(In reply to Milan Sreckovic [:milan] from comment #9)
> Sushil, this is QRD?  Sotaro, do we have one of those?

I have a QRD deivice.

Comment 11

[Sotaro Ikeda [:sotaro]]

(In reply to bhargavg1 from comment #6)
> (In reply to Jason Smith [:jsmith] from comment #5)
> > Without a video, we do not have an understanding of the impact here, which
> > means we can't block on this. Please renominate if the video is provided.
> 
> Video shared at,
> https://drive.google.com/file/d/0B0zTAnPOpx-xbk5uRWdSWDUyOUE/edit?usp=sharing
> 
> Bringing back 1.4? please check if status needs to be updated

From the video, it seems similar to Bug 1008026.

Comment 12

[Sotaro Ikeda [:sotaro]]

> > 
> > Bringing back 1.4? please check if status needs to be updated
> 
> From the video, it seems similar to Bug 1008026.

Bug 1011460 is a similar bug for b2g v1.4 and v2.0.

Comment 13

[Sotaro Ikeda [:sotaro]]

From From Bug 1011460 Comment 38, Bug 1011460 is fixed on b2g-v1.4 on 2014-06-06(today).

Comment 14

[Sotaro Ikeda [:sotaro]]

Sushi, can you test again with the environment that have Bug 1011460 fix?

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

Assigning to Punam who fixed bug 1011460 while waiting for Sushil to confirm that fixed it.

Comment 16

[Punam Dahiya [:pdahiya]]

(In reply to Joshua Mitchell from comment #8)
> Issue does NOT repro on 1.4 Flame
> Environmental Variables:
> Device: Flame 1.4
> Build ID: 20140604100718
> Gaia: 1f238df7ac68a73a4ceb27391a204c800f38ab1c
> Gecko: a7b7f1b579cc
> Version: 30.0 (1.4) 
> Firmware Version: v10G-2
> 
> Issue does NOT reproduce on 2.0 Flame
> Environmental Variables:
> Device: Flame 2.0
> Build ID: 20140605061016
> Gaia: 908f94fda04462001ece86e6b6c15ad8b05f7526
> Gecko: 219b3ed1b996
> Version: 32.0a1 (2.0) 
> Firmware Version: v10G-2
 
Not able to replicate this issue on my device. Please share the buildId and device name where this issue can be reproduced. Thanks

Comment 17

[Punam Dahiya [:pdahiya]]

I have tested on below environment and failed to replicate the issue reported
Device Flame, 
Build Id:20140611000202 
OS Version: 1.4

Comment 18

[Pi Wei Cheng [:piwei] (inactive)]

Please specify on what task you'd like QA Wanted to complete. Comment 8 already fulfilled testing on 1.4 and 2.0. Please needinfo the bug reporter if more info is needed in order to repro the bug because we QA team don't have that info.

NI JMitchell because I removed the qawanted keyword.

Comment 19

[Punam Dahiya [:pdahiya]]

Sorry for not being specific. As requested in #comment16, I would like to know the buildId and device name where this issue can be reproduced. Sushil, can you help with this info. Thanks

Comment 20

[bhargavg1]

(In reply to Punam Dahiya from comment #19)
> Sorry for not being specific. As requested in #comment16, I would like to
> know the buildId and device name where this issue can be reproduced. Sushil,
> can you help with this info. Thanks

I believe the reason you don't see this issue on flame is because its of lower resolution, 480x800

Can you try to reproduce this on either 720p/1080p device

To double confirm on the resolution can you check your dmesg logs and look for |mdss_fb_register| for |FrameBuffer[0]|

Comment 21

[Punam Dahiya [:pdahiya]]

(In reply to bhargavg1 from comment #20)
> (In reply to Punam Dahiya from comment #19)
> > Sorry for not being specific. As requested in #comment16, I would like to
> > know the buildId and device name where this issue can be reproduced. Sushil,
> > can you help with this info. Thanks
> 
> I believe the reason you don't see this issue on flame is because its of
> lower resolution, 480x800
> 
> Can you try to reproduce this on either 720p/1080p device
> 
> To double confirm on the resolution can you check your dmesg logs and look
> for |mdss_fb_register| for |FrameBuffer[0]|

I checked and my flame resolution in dmesg shows 480x854. I don't have 720p/1080p device. 

Also it's unclear from comments above if it's only 1.4 specific issue or replicable in 2.0/latest m-c builds. If it's 1.4 specific, downsampling changes for gallery has landed today  in 1.4 - See Bug 1002593. It will be good to test if this issue is replicable after 1002593 fixes in.

Unassigning myself and needinfo Hema to assign it to someone with 720/1080 device to replicate issue. Thanks

Comment 22

[David Flanagan [:djf]]

Bug 1011460 is completely unrelated to this one. In that case we were decoding large wallpaper images at full size. Too much image memory was being used and gecko handled it badly.  The fix in that patch is completely specific to the wallpaper app and will have no effect on Gallery.

Comment 23

[David Flanagan [:djf]]

Once again, CAF is asking is to block on bugs that manifest in their devices but which we have no way to reproducing.  I have 9 different phones on my desk, but none of them have a 720x1280 screen. This happens over and over again for the media team. If you're going to file bugs against our apps, we need access to the hardware you're using.

Having said that, the size of the thumbnail image is based on the size of the screen. I will try to reproduce this on a flame by making the thumbnails artificially large as if we were on a bigger screen.

Comment 24

[David Flanagan [:djf]]

I can reproduce this on my 1.4 Flame if I artificially force the thumbanails to be 320x320, which is what they'd be on a 720p device. Normally on the Flame they are something like 214x214. The bigger thumbanils require more than twice the memory.  The gray squares are presumably the result of gecko trying to swap images in and out of memory. Probably we're exceeding the image.mem.max_decoded_image_kb pref or something like that.  If the QRD device in question has a lot of memory consider adjusting that pref to match your device.

Also, though, in 1.4 gallery is using CSS background-image to display thumbnails, and gecko isn't smart about not decoding the ones that are not visible. So we use the tag_visibility_monitor.js utility to try to manage that ourselves.  There are parameters than can be tweaked (see gallery.js:400) to adjust how aggressive it is about encoding and decoding images.  Perhaps these parameters could be made sensitive to the screen size.

In 2.0 and master we have switched (in bug 967089) to using regular images and not using the visibility monitor code. With regular images we can just let gekco handle decoding images as they get close to being visible. Our best bet would just be to uplift that patch to v1.4. I'll try that and see if it fixes the bug on the Flame.

Comment 25

[David Flanagan [:djf]]

Attachment: uplift patch from bug 967089

Uplifting the patch from bug 967089 resolves the issue for me. If this also fixes it for the QRD device, then I think we're done here.

Comment 26

[David Flanagan [:djf]]

Sushil: Does the attached patch resolve the bug for you?

Sotaro: You said you have a QRD device to try this on. Does it fix the issue for you? After being able to reproduce this myself, I agree with you that this has a similar cause to the wallpaper bug. For the wallpaper, however, we were displaying large images and trying to keep them all visible at the same time, so the flickering never stopped.  Do you think that what we were seeing in the wallpaper bug and in this bug is just that we are exceeding image.mem.max_decoded_image_kb?  If so, then maybe we should consider changing our build process so that higher-end devices with bigger screens get larger values for that pref. The value should be based on total device memory or on screen resolution, perhaps.  Or if you do not think we are exceeding that preference, could it be that there is some other underlying bug that is causing gecko to release images too easily?

Comment 27

[Sotaro Ikeda [:sotaro]]

djf, if Sushil is busy today, I am going to check it. But before doing confirmation, I need to reproduce the problem on qrd device at fist. I do not know the answers to your questions. If I can reproduce the problem, I am going to check them.

Comment 28

[Sushil]

I do not have v1.4 tip qrd build ready to test the patch mentioned above. I can test it on Monday. If someone has a build ready, please check and update here. Thanks!

Comment 29

[Sotaro Ikeda [:sotaro]]

I tested the patch on qrd8X26 by using ROM that created by using caf_build_v2.sh. But the problem is not fixed. To test the path, I use a 1530*1845 jpg file got from internet. And stored 200 pic files that copied the jpg file.

And when I stored more than 400 pic files on sdcards, it was very hard to scroll the gallery. When I tried to scroll the gallery, the app often move to selected view.

Comment 30

[Sotaro Ikeda [:sotaro]]

I am going to check about the question in Comment 26 on Monday.

Comment 31

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #29)
> 
> And when I stored more than 400 pic files on sdcards, it was very hard to
> scroll the gallery. When I tried to scroll the gallery, the app often move
> to selected view.

Sorry, this was before applying patch. After applying the patch, I did not saw the above problem.

Comment 32

[David Flanagan [:djf]]

(In reply to Sushil from comment #28)
> I do not have v1.4 tip qrd build ready to test the patch mentioned above. I
> can test it on Monday. If someone has a build ready, please check and update
> here. Thanks!

Sushil,

Sotaro's test seems positive, but I'd like confirmation from CAF that this will resolve the bug before I land the patch into 1.4. So please test and let me know how it goes.

Comment 33

[Sushil]

(In reply to David Flanagan [:djf] from comment #32)
> Sushil,
> 
> Sotaro's test seems positive, but I'd like confirmation from CAF that this
> will resolve the bug before I land the patch into 1.4. So please test and
> let me know how it goes.

Yes, I tested with the patch mentioned in Comment 25. The user experience is much better now. The patch fixes this bug. Thanks!

Comment 34

[David Flanagan [:djf]]

Landed patch (uplifing bug 967089) in v1.4: https://github.com/mozilla-b2g/gaia/commit/c6ec00c1981eb4a03927ed70657d9541f3144cfb

Comment 35

[[:SalvadorR]]

Found similar test case covering issue. https://moztrap.mozilla.org/manage/case/1517/ Change: Prerequisite from 12 photos to 60 photos in device.

Comment 36

[KTucker [:KTucker][Inactive 3/4/2016]]

Updated the prerequisite and added expected results to look for any anomalies when scrolling through thumbnails to this test case:

https://moztrap.mozilla.org/manage/cases/?filter-id=1517