The two places we do extra work when the homescreen goes to the background are - here [1]. This may toss out some caches and initiate what should be light collection of dead objects. - here [2]. This will throw out all "onscreen" graphics resources. If we can get better performance by conditioning these on BACKGROUND_HOMESCREEN, we should consider doing that evaluated against negative consequences. [1] http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ProcessPriorityManager.cpp#571 [2] http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp?force=1#9164

> If we can get better performance by conditioning these on BACKGROUND_HOMESCREEN What is/are the performance metric/s you're interested in here? Is it just "time between pressing the home button and the homescreen showing," or is it something else?

That's the main one.

If we can, we should profile what the homescreen is doing after you press the home button. Is it actually spending a lot of time decoding images? I don't think the minimize-memory-usage is throwing anything significant away other than images, in this case, but maybe it is, and hopefully we'd see that in the profile.

Agreed; note, this is an "Investigate ..." bug, not a "Fix ..." one.

Might be a nice user-perceivable win in prime real estate, but not proven out yet.

I guess this better applies to this Bug: (Florian Bender from Last Comment Bug 823284 comment #11) > How about capturing the complete last known state of the Homescreen and save > it as one big image. Then show this image when returning to the homescreen > until everything else is ready. Is this sensible at all? Will this help? > Will this reduce or increase memory usage (Note: we may be able to discard > even more mem data because we have a "saved state" the User sees before > everything needs to be reparsed/recalculated/repainted)? > > This may actually work for all apps. And I think iOS does this (at least > with some apps).