Open
Bug 1047096
Opened 11 years ago
Updated 3 years ago
Do not display progressive JPEGs progressively if they're too large, since doing so wastes memory and CPU
Categories
(Core :: Graphics: ImageLib, defect)
Core
Graphics: ImageLib
Tracking
()
NEW
People
(Reporter: seth, Unassigned)
Details
(Whiteboard: [MemShrink:P3])
When we decode progressive JPEGs progressively, libjpeg-turbo has to allocate an internal buffer large enough to hold the entire image. This is in addition to the decoded data that we store, managed by imgFrame. For very large images on memory-constrained devices (think B2G), this additional buffer could mean the difference between OOMing and decoding the image successfully. Such devices are also slow, and decoding progressively requires significantly more computational effort than decoding non-progressively.
For both of these reasons, but particularly because of the memory concerns, we should add a pref that specifies a maximum size for progressive decoding. Above that size, we won't decode progressively and won't display the image until it's completely loaded. This is vastly preferable to running out of memory!
| Reporter | ||
Comment 1•11 years ago
|
||
It looks like actually libjpeg-turbo stores a buffer of DCT coefficients when progressively decoding, not a buffer of pixel data. That doesn't really change any of the conclusions above, though it means the magnitude of the memory savings is smaller than it would be with pixel data.
Comment 3•11 years ago
|
||
Progressive JPEGs are becoming more and more popular (proof: http://calendar.perfplanet.com/2012/progressive-jpegs-a-new-best-practice/ + http://www.webmonkey.com/2013/01/the-return-of-the-progressive-jpeg/ + other search results on Progressive JPEG, I heard that SPDY even "translates" usual JPEG to progressive ones if the size is over 10Kb), so one may expect them to be quite common.
If you're asking how common is that case of OOMing, I doubt that anyone can give any estimate.
Comment 4•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.
Assignee: seth.bugzilla → nobody
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•