Last Comment Bug 1124084 - Flip on downscale-during-decode on all platforms
: Flip on downscale-during-decode on all platforms
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: unspecified
: All All
-- normal (vote)
: mozilla40
Assigned To: Seth Fowler [:seth] [:s2h]
: Milan Sreckovic [:milan]
Depends on: 1143506 1143509 1144899 1145443 1145560 1164372 1180317
Blocks: ddd 1144286 1140619 1167849
  Show dependency treegraph
Reported: 2015-01-21 00:27 PST by Seth Fowler [:seth] [:s2h]
Modified: 2015-07-09 16:13 PDT (History)
9 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Flip on downscale-during-decode everywhere (4.83 KB, patch)
2015-01-21 00:28 PST, Seth Fowler [:seth] [:s2h]
tnikkel: review+
Details | Diff | Splinter Review
Flip on downscale-during-decode everywhere (5.37 KB, patch)
2015-03-17 13:27 PDT, Seth Fowler [:seth] [:s2h]
no flags Details | Diff | Splinter Review

Description User image Seth Fowler [:seth] [:s2h] 2015-01-21 00:27:29 PST
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.
Comment 1 User image Seth Fowler [:seth] [:s2h] 2015-01-21 00:28:50 PST
Created attachment 8552285 [details] [diff] [review]
Flip on downscale-during-decode everywhere

Here's the patch.
Comment 2 User image Seth Fowler [:seth] [:s2h] 2015-01-21 00:30:11 PST
Try job here:
Comment 3 User image Seth Fowler [:seth] [:s2h] 2015-03-03 18:21:22 PST
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:
Comment 4 User image Carsten Book [:Tomcat] 2015-03-04 00:11:07 PST
sorry had to back this out in since one of this changes caused a perma failure like:
Comment 5 User image Seth Fowler [:seth] [:s2h] 2015-03-15 16:17:22 PDT
OK, this should be ready to land after bug 1143506 and bug 1143509. Here's a try push with all of that stuff included:
Comment 6 User image Seth Fowler [:seth] [:s2h] 2015-03-17 12:17:02 PDT
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.
Comment 7 User image Seth Fowler [:seth] [:s2h] 2015-03-17 12:24:12 PDT
I filed bug 1144286 about reenabling that test.
Comment 8 User image Seth Fowler [:seth] [:s2h] 2015-03-17 13:27:07 PDT
Created attachment 8578863 [details] [diff] [review]
Flip on downscale-during-decode everywhere

Updated the patch to make us skip 944353.jpg on B2G.
Comment 9 User image Seth Fowler [:seth] [:s2h] 2015-03-17 14:00:31 PDT
Comment 10 User image Carsten Book [:Tomcat] 2015-03-18 05:55:29 PDT
Comment 11 User image Ryan VanderMeulen [:RyanVM] 2015-03-20 10:02:22 PDT
Backed out per discussion w/ seth.
Comment 12 User image Seth Fowler [:seth] [:s2h] 2015-05-06 12:54:54 PDT
Comment 13 User image Seth Fowler [:seth] [:s2h] 2015-05-06 12:55:30 PDT
^ re-pushed because the blocking bugs are now all fixed.
Comment 14 User image Carsten Book [:Tomcat] 2015-05-07 06:44:19 PDT
Comment 15 User image Milan Sreckovic [:milan] 2015-05-25 10:25:56 PDT
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.
Comment 16 User image Seth Fowler [:seth] [:s2h] 2015-05-27 15:44:56 PDT
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.
Comment 17 User image Sylvestre Ledru [:sylvestre] 2015-06-01 01:16:40 PDT
Added to the 40 release notes "JPEG images use less memory when scaled and can be painted faster" as wording

Note You need to log in before you can comment on or make changes to this bug.