Open Bug 1462431 Opened 2 years ago Updated 2 years ago

Expand scope of sizes we can downscale-on-decode at


(Core :: ImageLib, enhancement, P3)




Tracking Status
firefox62 --- affected


(Reporter: aosmond, Assigned: aosmond)


(Whiteboard: [gfx-noted])


(1 file)

We should support downscaling when one dimension is equal to or less than the native image size. For example, 32000x100 should allow downscaling to 100x100. Additionally if we want 200x200, we should allow downscaling to 200x100. While the drawing will still need to upscale, it will only need to upscale in one dimension. The display quality should be unaffected, and our memory footprint will be lower.
Assignee: nobody → aosmond
Priority: -- → P3
Whiteboard: [gfx-noted]
Attachment #8976675 - Flags: review?(tnikkel)
Attachment #8976675 - Flags: review?(tnikkel) → review+
Pushed by
Expand image downscale-on-decode to perform best effort sizing. r=tnikkel
Backout by
Backed out changeset 272880e5ca08 for failing on /test/unit/test_imgtools.js
Backed out changeset 272880e5ca08 (bug 1462431) for failing on /test/unit/test_imgtools.js 

Backout link:

Push with failures:

Log link:

Log snippet: 
00:36:19     INFO -  TEST-START | image/test/unit/test_imgtools.js
00:36:19  WARNING -  TEST-UNEXPECTED-FAIL | image/test/unit/test_imgtools.js | xpcshell return code: 0
Flags: needinfo?(aosmond)
It appears with my changes we are now using high quality scaling to produce a frame at 32x16, where as before it would produce a 32x32 unscaled frame which was subsequently downscaled (not high quality) using the draw target. This is why the results are different. I will regenerate the image files.

(There is also lots of room to improve in imgTools and at least some of this code is still used by things like the favicon service. We shouldn't be recreating the surface if we already have a data surface, and we probably should be using skia instead of cairo if we must use a draw target to rescale. Sigh. New bug?)
Flags: needinfo?(aosmond)
Pushed by
Expand image downscale-on-decode to perform best effort sizing. r=tnikkel
Backed out again because of Wr3 failures. Not a real problem, just slight scaling differences I believe but now I want to force it to run all tests on try to avoid another failure coming out of the woodwork...
Backout by
Backed out changeset 6c8bf287d25b for web platform reftest failure. r=aosmond
It seems the failing tests only run on Linux, given there is no failure on Mac/Windows/Android:

WebRender and baseline yield different failures due to choosing to scale the images in wildly different ways:

I can easily add fuzzing for the given tests although I do have some mild concern something is going wrong with the test. Further more, I am unable to reproduce the failures locally.
Also, I thought downscale on decode is disabled during most reftests by default. Hm. The evidence is clear that it is enabled however. Maybe the webplatform reftests are special.
With downscaling disabled:

Two unexpected passes that can be corrected, and two small amounts of fuzz.
You need to log in before you can comment on or make changes to this bug.