Once we've baked a Nightly with bug 1124072, I'll land the patch in this bug to flip on downscale-during-decode everywhere. I thought carefully about whether to flip on downscale-during-decode everywhere, as it definitely works better in conjunction with decode-on-draw. My hypothesis is that it's worthwhile even on platforms without APZ (where we don't decode-only-on-draw) because it should cause the steady state memory usage of any web page to be the same or lower. If we encounter any significant regressions as a result of enabling it on those platforms, we can pref it off there.

Here's the patch.

Try job here: https://tbpl.mozilla.org/?tree=Try&rev=af48a5b2b274

OK, this got delayed so long that it seemed better to just wait for 39, but I think we're ready to go now. Pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/e41d35b40ba9

sorry had to back this out in https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=25f00181e134 since one of this changes caused a perma failure like: https://treeherder.mozilla.org/logviewer.html#?job_id=7169706&repo=mozilla-inbound

OK, this should be ready to land after bug 1143506 and bug 1143509. Here's a try push with all of that stuff included: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9fe8a4b22053

So there's still a timeout on the 944353.jpg test despite bug 1143506 and bug 1143509. The reason is pretty simple: before downscale-during-decode, decoding that image on B2G failed immediately, because it's huge. After downscale-during-decode, we actually *can* decode it on B2G, but it takes a very long time and slows things down enough that we get timeouts. I have plans for improving the performance of the Skia downscaler, but I don't think it makes sense to wait for those changes to flip on downscale-during-decode, since this is after all a truly titanic image and not representative of most web content. I'm going to skip this test on B2G as part of this push and file a bug about reenabling it in the future.

I filed bug 1144286 about reenabling that test.

Updated the patch to make us skip 944353.jpg on B2G.

Pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/c5af69669855

Backed out per discussion w/ seth. https://hg.mozilla.org/integration/mozilla-inbound/rev/83737ac1ed54

^ re-pushed because the blocking bugs are now all fixed.

This is a big deal, when it comes to memory consumption for images, but I'll leave it to Seth to either give us the release note wording or say we don't need it.

Release Note Request (optional, but appreciated) [Why is this notable]: Major improvements in memory usage for images. Each image is scaled in memory to the exact size at which we'll paint it; we no longer need a copy of the image at its original size. This will have an especially big impact on mobile devices, where we are almost always displaying scaled down versions of images. On top of the memory usage improvements, this will help painting performance because we will no longer need to scale during painting. Right now this only applies to JPEG images, so I'll mention that in the wording below. [Suggested wording]: JPEG images now use less memory when scaled and can be painted faster. [Links (documentation, blog post, etc)]: I don't have one yet, but I will put one together.

Added to the 40 release notes "JPEG images use less memory when scaled and can be painted faster" as wording