Flip on downscale-during-decode on all platforms

RESOLVED FIXED in Firefox 40



5 years ago
4 years ago


(Reporter: seth, Assigned: seth)


(Blocks 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(firefox40 fixed, relnote-firefox 40+)



(1 attachment, 1 obsolete attachment)

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.
Attachment #8552285 - Flags: review?(tnikkel)
Attachment #8552285 - Flags: review?(tnikkel) → review+
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:

Blocks: 1140619
Depends on: 1143506
Depends on: 1143509
OK, this should be ready to land after bug 1143506 and bug 1143509. Here's a try push with all of that stuff included:

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.
Blocks: 1144286
I filed bug 1144286 about reenabling that test.
Updated the patch to make us skip 944353.jpg on B2G.
Attachment #8552285 - Attachment is obsolete: true
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Depends on: 1144899
Depends on: 1145443
Backed out per discussion w/ seth.
Resolution: FIXED → ---
Target Milestone: mozilla39 → ---
^ re-pushed because the blocking bugs are now all fixed.
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Depends on: 1164372
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.
relnote-firefox: --- → ?
Flags: needinfo?(seth)
Blocks: 1167849
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.
Flags: needinfo?(seth)
Added to the 40 release notes "JPEG images use less memory when scaled and can be painted faster" as wording
No longer depends on: 1180317
Depends on: 1180317
You need to log in before you can comment on or make changes to this bug.