1224268 - The new homescreen intermittently redraws icons with flicker when going home

Status: RESOLVED WONTFIX

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

Description

[Mihai Barbat]

User-Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

I am using 20151112030244 OTA on a Flame phone and the new homescreen always redraws the apps when closing an app. This give a very bad impression of the performance of the IS because you see the icons reappearing one by one on the screen.

Comment 1

[Chris Lord [:cwiiis]]

(In reply to Mihai Barbat from comment #0)
> User-Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0
> 
> I am using 20151112030244 OTA on a Flame phone and the new homescreen always
> redraws the apps when closing an app. This give a very bad impression of the
> performance of the IS because you see the icons reappearing one by one on
> the screen.

Sounds like the homescreen is getting killed in the background - are you on a low-memory profile?

New homescreen memory use falls below verticalhome, I'm not sure there's too much we can do here. There is definitely still low-hanging fruit for memory savings, but not huge ones I don't think.

Comment 2

[Mihai Barbat]

I have 1024 MB set up, the max RAM from my Flame!

Comment 3

[Chris Lord [:cwiiis]]

In which case, maybe something's triggering a platform crasher (I don't see this on a Z3C, but then that does have 2gb ram - pretty certain the homescreen is using very little memory though, I frequently have a multitude of apps open and nothing gets killed)...

Could you attach a logcat taken after the homescreen redraws, and perhaps record a video so I can see exactly what happens?

Comment 4

[Mihai Barbat]

I opened the Marketplace app and then I close it. You can see how the icons are repainted afterwards:

here is the video: https://www.youtube.com/watch?v=DhiOrSRlz1E

Comment 5

[Mihai Barbat]

Attachment: 2015-11-16-19-52-57.zip

Here are the logs

Comment 6

[Chris Lord [:cwiiis]]

That's... strange. This seems to happen any time you go home in 4-column mode, I don't see it in 3-column.

The homescreen doesn't appear to be restarting, it just seems to redraw (not sure why that is, but I assume due to layerisation/flattening), but why the images disappear/reappear, I don't know...

The homescreen doesn't do anything in particular when showing/hiding (just makes sure that edit mode isn't activated).

Not sure where to place the blame yet, but I'll continue to look into it.

Comment 7

[Chris Lord [:cwiiis]]

Ok, this only seems to happen when entering the task manager from an app, then exiting to the homescreen. Maybe related to the changes from bug 1216523.

STR:

- Switch homescreen to 4-columns mode
- Load any app (say 'Browser')
- Enter task manager
- Press home button
[Unexpected: Observe flash]

Comment 8

[Chris Lord [:cwiiis]]

Just checked, the changes in (and related) to bug 1216523 have no effect on this.

Comment 9

[Chris Lord [:cwiiis]]

Ok, just seen this in 3-column mode just going home from the Facebook app, no task manager involved. Think this is a regression, I would have noticed this. Easiest to reproduce with the steps on comment #7.

Let's see if we can get a window.

Comment 10

[Mihai Barbat]

The issue also happens with the pinned pages

Comment 11

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

QAwanted to branch check first.

Comment 12

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

Confirmed that bug is reproducible in central with Flame and Aries with STR at comment 7.

Device: Aries 2.6 Master
BuildID: 20151119162551
Gaia: ffaade435bb9c3005fd6c9b7ee1cd17b90e08cbf
Gecko: a523d4c7efe2f43dd6b25a176c07b729918d550f
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Device: Flame 2.6 Master
BuildID: 20151119065326
Gaia: ffaade435bb9c3005fd6c9b7ee1cd17b90e08cbf
Gecko: a523d4c7efe2f43dd6b25a176c07b729918d550f
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (2.6) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

-------

Both Flame 2.5 and Aries 2.5 are unaffected. Homescreen icons do not flash while in four columns after entering task manager. Repro rate: 0/10 on each device.

Device: Flame 2.5
BuildID: 20151119161153
Gaia: 28d63cf3bdc4417f7ad8cab2230f096bf9f6d3b5
Gecko: 497118efc1414c2825a8bd17b38721888c3875ca
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a2 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Device: Aries 2.5
BuildID: 20151119161838
Gaia: 28d63cf3bdc4417f7ad8cab2230f096bf9f6d3b5
Gecko: 497118efc1414c2825a8bd17b38721888c3875ca
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 44.0a2 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

-----

Working on getting the window.

Comment 13

[Chris Lord [:cwiiis]]

Possibly the same thing that causes https://bugzilla.mozilla.org/show_bug.cgi?id=1225934 ?

Comment 14

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

b2g-inbound regression window:

Last Working
Device: Flame 2.6
BuildID: 20151105100631
Gaia: cf0703f147e17bea1b18b58ada82625151238220
Gecko: 9875f804994f1521d9d60bc3c34c0ac4fa4c667f
Version: 45.0a1 (2.6) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

First Broken
Device: Flame 2.6
BuildID: 20151105010534
Gaia: cf0703f147e17bea1b18b58ada82625151238220
Gecko: 0f15d62411bfabd985586bb7e75d33702af0a7a3
Version: 45.0a1 (2.6) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=9875f804994f1521d9d60bc3c34c0ac4fa4c667f&tochange=0f15d62411bfabd985586bb7e75d33702af0a7a3

Caused by changes made in Bug 1212833.

Comment 15

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Vivien this issue seems to have been caused by the changes in bug 1212833.  Can you please take a look?

Comment 16

[Gabriele Svelto [:gsvelto]]

Sounds plausible, the memory minimization should be cancelled in this scenario but we might be hitting some kind of race that prevents it.

Comment 17

[vnicolas]

I may be wrong but I think this "issue" or the regression is not exactly where you expect it to be. This behavior is what I would expect based on our current codebase.

Not sure when it has regressed but my patch in bug 1212833 may have fixed a race condition that was preventing this behavior to happens. ('fixed' in a pretty poor way as it is timer based - i have to admit that).

Now, I'm not saying this is a great behavior. And I think the root cause is that the default settings of b2g are too agressive (like bug 1226153) for some devices. For devices like the Flame or the Aries it sounds fine to trade some memory for a better UX.

In fact I was hoping to fix this kind of things fixed by our gfx/images friends in bug 1002430 with has triggered the meta bug 1049673. But none of those has actually create any tractions.

So in my opinion the right way to fix this behavior (which happens for all apps - not only the homescreen) would be to have a smart behavior based on the amount of memory available for the device.

So for this particular bug, the way to fix it would be to alter the code at http://mxr.mozilla.org/mozilla-central/source/image/imgLoader.cpp#1282 and make it discard the image cache depending on a preference.

This preference could either be:
 -1 Discard image cache based on the available amount of memory
 0  Never discard the image cache on low-priority changes
 1  Always discard image cache on low-priority changes

That would be great to have such preference since this will move b2g away from assuming it always run on a device with a very limited amount of RAM.

Now, I may be wrong and maybe we fixed that intentionally but I doubt it, especially since the behavior before my patch is memory inefficient. And while it is good for some high-end devices, it is bad for some low-end devices.

Comment 18

[vnicolas]

I guess I have provided the requested info here. If someone want to fix it properly and what I have described is not enough I can give more informations.

If nobody wants to dive into it, I guess I can do the patch myself but I will be really happy to empty my current patch queue!

Comment 19

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Gabriele do you know who could act on the information in comment 17?

Comment 20

[vnicolas]

Attachment: discard.cache.on.background.patch

Here is more or less the patch I was thinking of. (untested).

Comment 21

[vnicolas]

But I'm not sure PR_GetPhysicalMemorySize works on b2g fwiw.

Comment 22

[vnicolas]

hmm. Even by commenting MinimizeCaches I still see the redraws. That sounds weird and my theory starts to seems broken. Will investigate a it more as soon I have some time to do so.

Comment 23

[Chris Lord [:cwiiis]]

Reassigning as per comment #22.

Comment 24

[Gabriele Svelto [:gsvelto]]

This is bizarre, it might be related to memory minimization but maybe not strictly to the image cache. I've tested this on a couple of device and I can reproduce it only using my production profile, with a clean one it doesn't happen. What I notice however even with a clean design is that when I go back to the homescreen the horizontal scrollbar appears, as if the home screen was being laid out again. I'll try turning off memory minimizations entirely and see what gives.

BTW I agree with Vivien here. That behavior (always minimize the background apps) was designed to fit a pre-Nuwa FxOS on devices with 256MiB of memory and far longer app startup times. Now it doesn't make much sense anymore and should be changed.

We could either turn it off entirely for phones with a sufficient amount of memory (e.g. >512MiB) and limit it on devices below that point so that it doesn't get in the way (for example by not minimizing the most recently backgrounded app but only starting with the 2nd or 3rd, we have an LRU of background apps already so that would be easy to implement).

Comment 25

[Gabriele Svelto [:gsvelto]]

I've just tried with memory minimization completely disabled and I can't repro the flickering icons (though I can still see the scrollbar appearing). If you're OK with it I'll steal the bug from you and change the policy to what I roughly described above.

Note that this wouldn't affect behaviour in low-memory conditions, the apps would still be minimized then. I'll just change the minimize-when-we-go-into-the-background part.

Comment 26

[vnicolas]

(In reply to Gabriele Svelto [:gsvelto] from comment #25)
> I've just tried with memory minimization completely disabled and I can't
> repro the flickering icons (though I can still see the scrollbar appearing).
> If you're OK with it I'll steal the bug from you and change the policy to
> what I roughly described above.

Sounds perfect to me :)

Comment 27

[Gabriele Svelto [:gsvelto]]

Excellent, stealing it :)

Comment 28

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH] Apply memory minimization only starting from the 3rd most recently used background applications

WIP patch, still requires some testing. This leaves the first two most recently backgrounded apps unaffected and minimizes memory starting with the third one. Note that it also applies to background perceivable apps which might help with audio glitches when sending an app playing music to the background.

Comment 29

[vnicolas]

(In reply to Gabriele Svelto [:gsvelto] from comment #28)
> Created attachment 8692509 [details] [diff] [review]
> [PATCH] Apply memory minimization only starting from the 3rd most recently
> used background applications
> 
> WIP patch, still requires some testing. This leaves the first two most
> recently backgrounded apps unaffected and minimizes memory starting with the
> third one. Note that it also applies to background perceivable apps which
> might help with audio glitches when sending an app playing music to the
> background.

You may want to add a pref to control the number of allowed backgrounded app before the memory is minimize. That may vary depending on the device (if we ever need to support something as agressive as the Tarako for example, or for devices with 2gb of ram).

This is completely unrelated to this particular bug, but for the app playing music I was playing with the idea of running the app on multiple processes. One for the music 'front-end' and one for the music 'back-end'. The back-end will be a kind of Media service (see https://github.com/vingtetun/gaia/tree/music_multi_process if you want to look at it if some days you have some time). It explains my questions about IAC and system messages of the past days :)

Comment 31

[Chris Lord [:cwiiis]]

With this fix, if you happen to switch between 4 apps before going back home, does that mean you'll see the flicker?

Comment 32

[vnicolas]

(In reply to Chris Lord [:cwiiis] from comment #31)
> With this fix, if you happen to switch between 4 apps before going back
> home, does that mean you'll see the flicker?

Yes. But this is really hard to go to 4 apps without ever going to home no ?

Comment 33

[vnicolas]

(In reply to vnicolas from comment #32)
> (In reply to Chris Lord [:cwiiis] from comment #31)
> > With this fix, if you happen to switch between 4 apps before going back
> > home, does that mean you'll see the flicker?
> 
> Yes. But this is really hard to go to 4 apps without ever going to home no ?

And if the number can be tweaked based on the device characteristic it will be more than this. TBH I think 3 is too agressive for a 512mb device, but is not aggressive enough for a 128mb device.

Comment 34

[Chris Lord [:cwiiis]]

(In reply to vnicolas from comment #32)
> (In reply to Chris Lord [:cwiiis] from comment #31)
> > With this fix, if you happen to switch between 4 apps before going back
> > home, does that mean you'll see the flicker?
> 
> Yes. But this is really hard to go to 4 apps without ever going to home no ?

What happens if you're browsing Facebook/Twitter and you open a few links? Seems like a really easy way to still hit this. I guess this won't happen if you closed each opened link immediately after opening it before opening the next (or will it?) - but our default UX makes that a really hard thing to do.

This, though desirable, doesn't seem like an adequate fix to me.

Comment 35

[vnicolas]

(In reply to Chris Lord [:cwiiis] from comment #34)
> (In reply to vnicolas from comment #32)
> > (In reply to Chris Lord [:cwiiis] from comment #31)
> > > With this fix, if you happen to switch between 4 apps before going back
> > > home, does that mean you'll see the flicker?
> > 
> > Yes. But this is really hard to go to 4 apps without ever going to home no ?
> 
> What happens if you're browsing Facebook/Twitter and you open a few links?
> Seems like a really easy way to still hit this. I guess this won't happen if
> you closed each opened link immediately after opening it before opening the
> next (or will it?) - but our default UX makes that a really hard thing to do.
> 
> This, though desirable, doesn't seem like an adequate fix to me.

Well that's always a story of what is the right tradeoffs between UX and memory management. Again if you have a high-end phones which can open multiples tabs in multiple processes without any of them beeing killed ever, I assume the LRU settings will be pretty high (at least 10).

For such a use case, one question can also be: do we really want to open your 10 tabs into 10 processes ? Or should we limit the number of processes in such a case to a few, let's say 2 or 3 ?

Again, don't get me wrong. I do not like those extra redraws - I hate them. But we need to find a solution that does not keep around all the app data, especially in word where it can be third party homescreen. The current behavior in a bug in the sense that it keeps all the image data of all apps. And decoded datas, as you likely know, may be pretty expensive.

Comment 36

[vnicolas]

For what it worth, I also believe that you may see glitche if you open more than 10 apps without ever going to the homescreen as the layer tree may have been discarded already.

Comment 37

[Chris Lord [:cwiiis]]

Right, so we either need to have some kind of priority so we don't minimise the homescreen unless absolutely necessary, or we need to fix the cause of the flicker so that this is a non-issue. It shouldn't be so easy to cause visual glitches without doing anything particularly special.

To a user, this is just a nasty-looking/feeling glitch that occurs for no apparent reason - all they see is that after browsing on Facebook/Twitter/whatever for a short while and going home to launch another app, it flickers.

Why are we presenting frames if loaded images that are visible on the screen aren't ready?

Comment 38

[Gabriele Svelto [:gsvelto]]

So Chris comments gave me something to think about; we decided to minimize background apps back in the day because it was better for apps to respond a little slower than to be killed outright and have to relaunch. So the real question is: when should we minimize app memory usage? The answer shouldn't be "when they're in the background" but rather "when we're going out of memory and we want to prevent them from being killed to make room".

We already have a mechanism for detecting low memory situation: the kernel low-mem trigger. The issue with that bit of functionality is that we're already using it for minimizing memory usage of the foreground apps when there's no more background apps to kill (e.g. one single very large web page, or a very large app such as a game). That scenario is still valid today and I wouldn't want to regress it but instead of leaving the low-mem trigger at a fixed level as we do now we could move it dynamically to help us decide when to minimize background apps.

So here's a rough proposal:

- Let's try to distinguish between two scenarios: a scenario in which we have a few background apps open and we're running out of memory to keep them around. I'll call this a soft low-memory condition. The other scenario will be when we've already killed background apps to make room for the perceivable/foreground ones and we're still running out of memory, I'll call that a hard low-memory condition.

- Apps sent into the background are not minimized unless we're in a soft low-memory condition. So as long as we have memory to spare we're letting apps burn as much memory as they want to improve responsiveness.

- To distinguish between the soft and hard low memory condition we need to modify the memory pressure detector to dynamically adjust the low-mem trigger. The trigger starts at the soft low-memory threshold which should be placed above the first LMK threshold (the one used to kill background apps). If it's activated we minimize background apps and move it to the hard low-mem threshold. Once there the trigger will work as it currently does (let all background apps die and then try to keep the remaining foreground ones alive).

- When an app is killed by the LMK we check the trigger level; if there's enough memory available we move the trigger back to the soft threshold again.

- To avoid flip-flopping quickly between the two states we can use an exponential back-off timer. An hysteresis isn't needed because the two thresholds should already behave like one.

- Additionally I'd like to add another optimization to the above: once a background app is minimized it won't be minimized again unless it's priority changed - even if we're still in a low memory condition. Minimizing the same background app multiple times as we currently do (in degenerate scenarios) only drains battery and reduces responsiveness for no practical benefit.

Does the above sounds reasonable? Obviously this will require a little more work but I might get it done by next week.

Comment 39

[Chris Lord [:cwiiis]]

I think that all sounds reasonable and I imagine minimising less will also improve performance (at the temporary cost of memory) - but there are still two situations that aren't addressed, that perhaps we need separate issues for:

- In this situation, the homescreen still gets no preferential treatment, but we know that the user is almost certainly going to reactive it at some time. We should raise its priority somehow (even if we have to explicitly check that an app is the homescreen).

- Minimising still causes images to flicker. Why is this? Why can we not fix this? A user is still likely to see this after running a game, or encountering a website with bad memory characteristics (there are still plenty of these sites, even on a high-end device, and especially with our current display-port behaviour).

Comment 40

[vnicolas]

(In reply to Chris Lord [:cwiiis] from comment #37)
> It shouldn't be so easy to cause
> visual glitches without doing anything particularly special.
> 

Sure that's what we are trying to fix here. Thanks for your suggestions about prioritizing the homescreen.

> To a user, this is just a nasty-looking/feeling glitch that occurs for no
> apparent reason - all they see is that after browsing on
> Facebook/Twitter/whatever for a short while and going home to launch another
> app, it flickers.

Again you don't need to convince me. I'm already convinced since at least 2 years... But at this point in time, memory was the priority.

> 
> Why are we presenting frames if loaded images that are visible on the screen
> aren't ready?

That's a good question - and to me it applies to much more than just the homescreen.
It happens during app launch for example, when apps are dancing in the user face. For this one I would like to add a new event like in bug 1211853. If you feel concerned about flickering, I will be happy to have your comments/solutions/suggestions in the mentioned bug or in the thread in dev-platform (as it is starting to sleep...).

Comment 41

[vnicolas]

(In reply to Chris Lord [:cwiiis] from comment #39)
> I think that all sounds reasonable and I imagine minimising less will also
> improve performance (at the temporary cost of memory) - but there are still
> two situations that aren't addressed, that perhaps we need separate issues
> for:
> 
> - In this situation, the homescreen still gets no preferential treatment,
> but we know that the user is almost certainly going to reactive it at some
> time. We should raise its priority somehow (even if we have to explicitly
> check that an app is the homescreen).

It keeps hurting me that you always want to prioritize the homescreen. It is really a story of probabilities.

While I agree that the homescreen is very likely to be accessed, it does not mean this is the ultimate app that should keep all its resources all the time, right ?

For example in the scenario you described before, if the user has opened a lot of urls from Facebook/Twitter. All those processes will be backgrounded, and so their resources will be freed in soft low memory. Does the homescreen is more important here than the next resources the user may look at ? 

And all those scenarios are tied to how the user use the phone. If a user use the gallery app all the time for example, but has opened once a big game that trigger a soft low memory situation. Do we want to minimize the gallery app or should we wait a bit, minimize a few other apps first, and see what happens ? (I think we would need a third trigger to achieve such a thing correctly).

Also if the user use a third party homescreen that consume a lot of resources, should we start to kill other apps he may used very often, or the music app, before asking the homescreen to minimize its memory usage ? (it is a much worse experience when an app has been killed than a glitch on one particular app).

TBH I don't think we would have a great memory minimization strategy until the threshold events are sent to Gaia, which can then take informed decisions about what to minimize first (we may need to let Gaia know, with a small browser API, how much memory is consumed by an app)

> 
> - Minimising still causes images to flicker. Why is this? Why can we not fix
> this? A user is still likely to see this after running a game, or
> encountering a website with bad memory characteristics (there are still
> plenty of these sites, even on a high-end device, and especially with our
> current display-port behaviour).

AFAIK decoded image data may be very expensive - and so it is a good target to be cleaned up. When the app starts to be visible again, then the app will try to display again, asking image datas to be redecoded on the IO thread.

Do you suggest to always keep them in memory ? Whatever the device is ?
Or to have a mechanism that tells you when all the image data of the viewport has been redecoded so you know when you can start to show the frame (which may lead to response lag when hitting home fwiw).



IMO, to be really smart about that, we would need to expose some of the about:memory informations to Gaia, which may then look at how much memory is consumed into which categories, mixing them up with some user data, and then output a decision.

Then we could decide to minimize the homescreen app, if it does not consume a lot of image memory, only when all other apps have been already minimized.

Comment 42

[Gabriele Svelto [:gsvelto]]

(In reply to Chris Lord [:cwiiis] from comment #39)
> I think that all sounds reasonable and I imagine minimising less will also
> improve performance (at the temporary cost of memory) - but there are still
> two situations that aren't addressed, that perhaps we need separate issues
> for:
> 
> - In this situation, the homescreen still gets no preferential treatment,
> but we know that the user is almost certainly going to reactive it at some
> time. We should raise its priority somehow (even if we have to explicitly
> check that an app is the homescreen).

The homescreen used to get preferential treatment but we've removed that to not penalize people using edge-swipe navigation (or any other form of non-homescreen navigation). Single-casing it is possible but not necessarily beneficial. For example w/o memory minimization my homescreen uses ~40MiB of USS, fully minimized it takes ~20MiB. When in use again after a minimization only ~27MiB because we've dropped a lot of memory that was used only at startup and is not needed at runtime. So there's a net benefit in minimizing it, we should just do it smartly enough that it doesn't annoys the user (e.g. as a last resort).

> - Minimising still causes images to flicker. Why is this? Why can we not fix
> this? A user is still likely to see this after running a game, or
> encountering a website with bad memory characteristics (there are still
> plenty of these sites, even on a high-end device, and especially with our
> current display-port behaviour).

That's because we need to re-decode the images. While it might be annoying it's a hell of a lot better than the alternative: the app has been killed because we were out of memory and we need to re-launch it, losing whatever state the user had put it in.

Comment 43

[Chris Lord [:cwiiis]]

I think your points are all valid, but I think this issue remains:

(In reply to Gabriele Svelto [:gsvelto] from comment #42)
> (In reply to Chris Lord [:cwiiis] from comment #39)
> > - Minimising still causes images to flicker. Why is this? Why can we not fix
> > this? A user is still likely to see this after running a game, or
> > encountering a website with bad memory characteristics (there are still
> > plenty of these sites, even on a high-end device, and especially with our
> > current display-port behaviour).
> 
> That's because we need to re-decode the images. While it might be annoying
> it's a hell of a lot better than the alternative: the app has been killed
> because we were out of memory and we need to re-launch it, losing whatever
> state the user had put it in.

That's not the alternative though, surely? The alternative is that we don't paint until the image is decoded again. Yes, there would be a latency penalty, but we have two options here:
1- Paint immediately, definitely show flicker
2- Wait to paint, show consistent visuals

The downside of 1 is that 100% of the time it will look glitchy. The downside of 2 is that sometimes, it may be a little slow. I would take 2 every time, but I'm sure we can be cleverer about this anyway - why don't we synchronously decode all images that are within the composition bounds, then asynchronously decode those images outside of them? Users are already used to seeing flickering when exposing new area after scrolling (e.g. checkerboarding), and hopefully by the time a user has made that decision we would have decoded those images anyway.

Comment 44

[Gabriele Svelto [:gsvelto]]

(In reply to Chris Lord [:cwiiis] from comment #43)
> That's not the alternative though, surely? The alternative is that we don't
> paint until the image is decoded again. Yes, there would be a latency
> penalty, but we have two options here:
> 1- Paint immediately, definitely show flicker
> 2- Wait to paint, show consistent visuals
> 
> The downside of 1 is that 100% of the time it will look glitchy. The
> downside of 2 is that sometimes, it may be a little slow. I would take 2
> every time, but I'm sure we can be cleverer about this anyway - why don't we
> synchronously decode all images that are within the composition bounds, then
> asynchronously decode those images outside of them? Users are already used
> to seeing flickering when exposing new area after scrolling (e.g.
> checkerboarding), and hopefully by the time a user has made that decision we
> would have decoded those images anyway.

That's an interesting idea but it's far beyond my understanding of gecko rendering/layout internals for me to act on it :) Maybe we should chop up this bug in multiple ones to address the various issues we discussed?

Comment 45

[vnicolas]

As I said on IRC we used to force Gecko to redecode images by calling AppWindow.waitForFullRepaint when transitioning to the homescreen. This is very expensive as it force a drawWindow in the background but it was working.

Someone has likely remove this behavior, relying on the fact that Gecko was not properly releasing memory. We can still add it back. But I think it will still be good to know if the app has been minimized in order to not do it when it is not necessary.

Comment 46

[Gabriele Svelto [:gsvelto]]

FYI I've started working on the patch I've described in comment 38. I'm not sure if it's appropriate to put it in this bug or to open a separate one just for it.

Comment 48

[Gabriele Svelto [:gsvelto]]

Comment on attachment 8692509 [details] [diff] [review]
[PATCH] Apply memory minimization only starting from the 3rd most recently used background applications

Marking this patch as obsolete because I'm opening another bug for the memory-trigger related work.

Comment 49

[Gabriele Svelto [:gsvelto]]

Resetting the assignment of this bug since I'll be actioning the memory part in bug 1234176

Comment 50

[Mihai Barbat]

I can confirm that with today's OTA for the Flame this issue is fixed and this bug can be closed.

Comment 51

[Gabriele Svelto [:gsvelto]]

(In reply to Mihai Barbat from comment #50)
> I can confirm that with today's OTA for the Flame this issue is fixed and
> this bug can be closed.

The issue has not been fixed, only mitigated when there's enough memory. To reproduce it one can force a memory minimization with the following STR:

1. From the homescreen open an app
2. Run from the commandline './tools/get_about_memory.py -m --no-auto-open --no-gc-cc-log' to minimize memory usage
3. Go back to the homescreen
4. Observe the icons flickering

To resolve this problem we should implement something along the lines of what Chris has outlined in comment 43. Chris can you open a bug to implement a proper fix for when the decoded images have been dropped and have it block this one? In the meantime I suggest reopening this bug.

Comment 53

[Armen [:armenzg]]

Closing all intermittent test failures for Firefox OS (since we're not focusing on it anymore).

Please reopen if my search included your bug by mistake.

Comment 54

[BMO Automation]

Firefox OS is not being worked on