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)

defect

Tracking

()

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!
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.
How common is this in practice?
Whiteboard: [MemShrink] → [MemShrink:P3]
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.

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: seth.bugzilla → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.