1145284 - [Gallery] Pictures and parts of pictures drop in and out / flicker when scrolling up and down in the Gallery

Status: VERIFIED FIXED

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

Description

[Joshua Mitchell (Inactive)]

Attachment: logcat_20150319_1149.txt

Description:
Scrolling in gallery is creating flickering; parts of pictures drop in and out, being replaced by the gray background. Sometimes entire pictures disappear momentarily. This seems to repro easier with more pictures and videos in your gallery.


Repro Steps:
1) Update a Flame to 20150319010201
2) Launch Gallery
3) Scroll up and Down


Actual:
Images and parts of images flicker in and out

Expected:
No flickering

Environmental Variables:
Device: Flame Master
Build ID: 20150319010201
Gaia: c39e15f631de80c69467fda0d4ea0bcda9e194ca
Gecko: cf1060d8ce9f
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (Master)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0


Repro frequency: 7/7
See attached: logcat, video: http://youtu.be/qT1W0vHQVoo

Comment 1

[Joshua Mitchell (Inactive)]

This issue does NOT reproduce on 2.2 

Device: Flame 2.2 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150318055750
Gaia: b8051d370ddf4e5bd8e7d8a19fb9eeb5fd6ffb39
Gecko: 41a61514461e
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (Master)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Comment 2

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

[Blocking Requested - why for this release]:

Regression from 2.2 and looks bad so nominating 3.0?

Comment 3

[Brogan Zumwalt [Inactive]]

Central Regression Window:

Unable to finish the Mozilla-Inbound window before end of day, will have full regression window by Monday morning.

Marking 2.2 as affected due to regression window.

Last working Central build:
Device: Flame 2.2
Build ID: 20141127034602
Gaia: 80bc1445959db79e9d2e947cc56e1eb7b0d3d0f0
Gecko: f1a873d55815
Version: 36.0a1 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First broken Central build:
Device:  Flame 2.2
BuildID: 20141127035837
Gaia: 80bc1445959db79e9d2e947cc56e1eb7b0d3d0f0
Gecko: 8d185a31024e
Version: 36.0a1 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0


Working Gaia with Broken Gecko issue DOES reproduce:
Gaia: 80bc1445959db79e9d2e947cc56e1eb7b0d3d0f0
Gecko: 8d185a31024e

Working Gecko with Broken Gaia issue does
Gaia: 80bc1445959db79e9d2e947cc56e1eb7b0d3d0f0
Gecko: f1a873d55815


Central Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f1a873d55815&tochange=8d185a31024e

Comment 4

[Brogan Zumwalt [Inactive]]

Mozilla-Inbound Regression Window:

Last working Mozilla-Inbound build: 
Device:Flame 2.2
BuildID: 20141126132636
Gaia: 0f7bb156969c5c838ff90ebc88d7691fc4d94310
Gecko: 8987ca07b80e
Version: 36.0a1 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First broken Mozilla-Inbound build:
Device: Flame 2.2
Build ID: 20141126134035
Gaia: 0f7bb156969c5c838ff90ebc88d7691fc4d94310
Gecko: 9cf92262a800
Version: 36.0a1 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0


Working Gaia with Broken Gecko issue DOES reproduce:
Gaia: 0f7bb156969c5c838ff90ebc88d7691fc4d94310
Gecko: 9cf92262a800

Working Gecko with Broken Gaia issue does NOT reproduce:
Gaia: 0f7bb156969c5c838ff90ebc88d7691fc4d94310
Gecko: 8987ca07b80e


Mozilla-Inbound Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8987ca07b80e&tochange=9cf92262a800


Issue appears to occur due to changes made in bug 1060869

Comment 5

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

Seth, can you take a look at this please? This might have been caused by the work done for bug 1060869

Comment 6

[Seth Fowler [:seth] [:s2h]]

Bug 1060869 changed the formula that we use for deciding how much memory to allocate to images. It may be that we ended up allocating less memory to images on the Flame because of this change, and that's why we're seeing the flickering - we're being forced to discard images aggressively because we're low on memory. I don't see any other obvious reason why bug 1060869 would cause this.

Probably the fix here just involves tweaking prefs. I will experiment with it once I can reproduce. (I probably need to take a lot more pictures so the Gallery uses more memory...)

Comment 7

[Seth Fowler [:seth] [:s2h]]

I investigated and I'm confident that the problem is not bug 1060869.

Even with a huge number of images in my gallery, I cannot reproduce this problem when the gallery contains *only* images. Memory usage is also very low even with a large number of images. However, adding just a few videos to the Gallery is enough to reproduce the problem.

What's happening is that something in the code path we use for displaying those videos is taking a huge amount of memory. That is causing the system to send memory pressure notifications. ImageLib gets those notifications and reacts by discarding some image data to free up memory. On B2G we don't know which images are visible for various reasons, so it just discards a bunch of random images, and if you're in the Gallery app there's a good chance that the images being discarded are on the screen.

Could ImageLib be smarter here? Sure, but that's not the root problem. Whatever is causing massive memory usage in this situation, which seems to be video related, is the problem.

An additional note: the regression range is wrong. I would not pay any attention to it. Bug 1057904 landed right before bug 1060869 and made us lock all images, even on B2G. That would obviously solve the problem here by preventing us from discarding any images, even when there is memory pressure, but it's behavior that we couldn't possibly ship because it would result in frequent OOMs. Bug 1060869 then came immediately afterwards and restored the normal behavior. So this regression range isn't to be trusted; to get an accurate one, you'd have to find one that excluded bug 1057904 and bug 1060869.

Anthony, can you triage this one, since it seems to actually be video related?

Comment 8

[StevenLee[:slee]]

Hi BroganZ,

I tried the latest 2.2 on pvt and cannot reproduce the problem. I put about 50 video files in the SD card. Here is the revision number.

Gaia-Rev        7024dd4c7a7c3616dc8f9f908759f00abc0deddd
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/79a8767e838e
Build-ID        20150324162501
Version         37.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150324.203451
FW-Date         Tue Mar 24 20:35:02 EDT 2015
Bootloader      L1TC000118D0

Can you also try on your device and turn on "Draw tile boarders"? I'm not sure if it is related to graphics problem. Thanks.

Comment 9

[Brogan Zumwalt [Inactive]]

I am reproducing on the latest Flame 2.2 from PVT with 164 pictures and no videos on internal storage. 

Video: http://youtu.be/nOia1EVq7oQ

Device: Flame 2.2
Build ID: 20150325002503
Gaia: aeee2a54caa8ffb875b96264b61d742b70689f22
Gecko: 556aca3e50ac
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 10

[StevenLee[:slee]]

Hi seth,

Please check comment 9, BroganZ tested with picture only and can reproduce the problem.
Thanks.

Comment 11

[Seth Fowler [:seth] [:s2h]]

As far as I can tell, this is just caused by low memory. I'm sure it's possible to reproduce it in the Gallery if you have enough pictures.

We need to determine where the memory is going before we can do anything else useful. On desktop Firefox, we could just check about:memory, but I don't know how to do this on B2G.

Comment 12

[StevenLee[:slee]]

(In reply to Seth Fowler [:seth] from comment #11)
> We need to determine where the memory is going before we can do anything
> else useful. On desktop Firefox, we could just check about:memory, but I
> don't know how to do this on B2G.
You can go to B2G/tools and run "get_about_memory.py". It retrieves the memory usage data and save the data to folder, "about-memory-x". Then you can open the "memory-reports" from about:memory.

Comment 13

[Seth Fowler [:seth] [:s2h]]

(In reply to StevenLee[:slee] from comment #12)
> You can go to B2G/tools and run "get_about_memory.py". It retrieves the
> memory usage data and save the data to folder, "about-memory-x". Then you
> can open the "memory-reports" from about:memory.

Thanks, that's useful.

Last week I was thinking about this problem, and I think there are really two bugs here:

(1) Various things are causing high memory usage on B2G, causing lots of memory-pressure events. I don't see much evidence that ImageLib is the culprit here so far.

(2) The way ImageLib reacts to memory-pressure events is not ideal, because it can discard images that are currently visible on B2G. This is because B2G (up to now) doesn't use image locking, which prevents this from happening on other platforms.

Over the weekend I landed bug 1148696, which enables image locking on B2G. That should eliminate problem (2), so while we probably still want to address issues like high memory usage of videos in the Gallery, you should no longer see image flickering as a result of that issue.

Can anyone verify that this fixed the problem on current trunk?

Comment 14

[StevenLee[:slee]]

(In reply to Seth Fowler [:seth] from comment #13)
> Over the weekend I landed bug 1148696, which enables image locking on B2G.
> That should eliminate problem (2), so while we probably still want to
> address issues like high memory usage of videos in the Gallery, you should
> no longer see image flickering as a result of that issue.
I discussed with Dominic about this problem. It should not related to the video. When we recorded a video from camera app, there will be 2 files stored, one is the video clip and the other is a jpeg file. When gallery app is running, it only loads the jpeg files instead of the video clips.

> 
> Can anyone verify that this fixed the problem on current trunk?
Hi BroganZ,

As comment 13, seth had landed bug 1148696. Can you verify this problem? Thanks.

Comment 15

[Seth Fowler [:seth] [:s2h]]

(In reply to StevenLee[:slee] from comment #14)
> I discussed with Dominic about this problem. It should not related to the
> video. When we recorded a video from camera app, there will be 2 files
> stored, one is the video clip and the other is a jpeg file. When gallery app
> is running, it only loads the jpeg files instead of the video clips.

That makes sense. It may just be that the JPEGs from those videos happened to be the ones that pushed things into a low memory situation on my device.

Comment 16

[Brogan Zumwalt [Inactive]]

Issue does not appear to reproduce on latest Flame 3.0, but bug 1149694 makes it difficult to say with absolute certainty. Verifying fixed. As latest Flame 2.2 is still affected I am leaving verifyme keyword awaiting uplift of bug 1148696 to 2.2.

No flickering observed when scrolling through Gallery with large amount of pictures (and some videos).

Device: Flame Master
Build ID: 20150331010203
Gaia: a249df8f4c84fe0a139741f05a534d36996ea7b8
Gecko: 8af276ab8636
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0


Device: Flame 2.2
Build ID: 20150331002503
Gaia: cc11248ab69f13e89416c8e6bb2e184187e72088
Gecko: 90a26917ee8f
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 17

[Seth Fowler [:seth] [:s2h]]

OK, great. Before we uplift bug 1148696, I want to land a patch in bug 1149786, as I think it makes sense to make those changes together.

Comment 18

[Seth Fowler [:seth] [:s2h]]

FWIW: I did go ahead and request uplift for bug 1148696. The change in bug 1149786 is a bit higher risk, I think, so I've changed my mind about landing those things together.