STR (1) Use the device heavily, opening many applications (2) Go back to homescreen frequently We get into a situation where most app->homescreen transitions have a brief jank where we decode and repaint the app icons. (Multiple decodes and paints! :( ) This is confusing our nextpaint logic. One potential fix is to be smarter about decoding ... I thought we would eagerly decode a lot of small images, but maybe they're uncached or we exceed a timeout. I suspect the images are being discarded because of lowmem events. So another potential option is to run less aggressive cleanups in the homescreen process. We can already distinguish it because it will be in the "homescreen" OOM class. bb? to get on the radar, not suggesting we block on this.

> I suspect the images are being discarded because of lowmem events. When a process goes into the background, we fire a low-mem event. That causes it to discard all of its decoded images, among other things. It's not clear what behavior you want here. We don't want to cache the homescreen's icons permanently; that just eats up RAM that needs to go to apps. Maybe you want us to avoid painting until we've decoded a few images?

In more detail, I think the options are (1) Tweak the sync decode params so that they work well for homescreen. But I don't know if these are the problem. (2) Less-eagerly discard decoded images; maybe we're tossing out the undecoded memory too? (3) Do something special when we go into background and we're the homescreen (4) Somehow make nextpaint work better with decoding, but that seems very hard

> (1) Tweak the sync decode params so that they work well for homescreen. But I don't > know if these are the problem. This will increase jank, though. If anything the inertia seems to be to sync-decode less often. See e.g. the push to get off-main-thread image decoding for B2G v.next (bug 716140); that's only helpful on a one-core machine inasmuch as it lets us ensure that we never decode for longer than one CPU timeslice. > (2) Less-eagerly discard decoded images; If you mean "discard decoded images on the homescreen after a timeout, instead of immediately," that does not solve the problem; it just makes it happen less-frequently. > maybe we're tossing out the undecoded memory too? I'm pretty sure imagelib never does this. Doing so would require us to ensure that the image was pinned into the HTTP cache, because we don't want to make an extra HTTP request for a given image. > (3) Do something special when we go into background and we're the homescreen We could keep all of the homescreen's images decoded and in memory, but that would mean less memory would be available to apps. Like I said in comment 1, it is not clear to me what's the behavior you're looking for here from the homescreen.

When we composite the homescreen to screen the first time it's shown, all the icons should be decoded and drawn. Icons trickling in one by one is terrible. Painting the homescreen sans icons once and then once with all decoded and drawn is not great but better than them popping in randomly. Ideally we would know which icons are visible and sync decode them (prioritize?), but yeah I know hahahaha.

> Ideally we would know which icons are visible and sync decode them (prioritize?) We decode visible images first, actually. But we do not sync decode them, because that would cause jank. And we only know which images are visible after they're ::Draw()'n, which means that we can't start prioritizing them until we've shown a blank spot where they belong.

(In reply to Justin Lebar [:jlebar] from comment #3) > > maybe we're tossing out the undecoded memory too? > > I'm pretty sure imagelib never does this. Correct. (Unless the document the image is loaded in is destroyed entirely, anyways.) (In reply to Justin Lebar [:jlebar] from comment #5) > > Ideally we would know which icons are visible and sync decode them (prioritize?) > > We decode visible images first, actually. But we do not sync decode them, > because that would cause jank. And we only know which images are visible > after they're ::Draw()'n, which means that we can't start prioritizing them > until we've shown a blank spot where they belong. Actually, we currently (on m-c) do 5ms of decoding synchronously when an image is drawn. This has not made it to beta, though. This was done in bug 792199, but it had a bug: bug 799335. It also exposed another bug, bug 802390. So uplifting is not without risk. (In beta, if we ask an image to decode and *then* draw it, we won't do any synchronous decoding before drawing.)

It sounds like what cjones wants here is some sort of paint coalescing. Don't paint the homescreen until we're "ready". But I don't know how that stuff works...

The behavior described in comment 6 sounds like it would handle the common case well, but it also sounds like it might be too risky. Would be interesting to a/b test with m-c.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #0) > We get into a situation where most app->homescreen transitions have a brief > jank where we decode and repaint the app icons. (Multiple decodes and > [...] > bb? to get on the radar, not suggesting we block on this. We discussed this during triage and decided that we could ship with brief jank. I've put it on the 1.x tracker.

Better control over image resources is a generally useful goal, and especially important for prime homescreen real estate.

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).

Is this still a problem?

(In reply to Dietrich Ayala (:dietrich) from comment #12) > Is this still a problem? I'd like to know this too. Is this still a problem on trunk? (Not 2.2, but trunk specifically, because bug 1148696 may have changed our behavior significantly here.) Adding qawanted so hopefully we can get this bug either confirmed or verified as fixed.