Created attachment 276521 [details] [diff] [review] Patch to remove jpeg scanline (and a memcpy) The JPEG decoder can let libjpeg directly decode scanline(s) to the buffer space of the Cairo image, so that we don't have to allocate a separate scanline for that. By putting the jpeg at the end of the image row, CMS conversion and then conversion to Cairo can happen in place (from 3 byte to 4 byte pixel). For greyscale, the jpeg data is put at begin of the image row, and then CMS converted to the end of the image row (as it converts also to 3 byte RGB), and then the conversion to 4 bytes Cairo pixels can also happen in place. Savings: * No more mInfo.mem->alloc_sarray for the scanline: this saves two mallocs: for the row array (4 bytes) and one for the scanline (3 bytes * image_width). * Memcpy operation for greyscale images (they are rare though). So, for our jpegs pictues taken with a 8M pixel camera, resulting in images of about 3000 x 2000, this saves an allocation of 9000 bytes for each image. (This may also fix bug 365653 as they are no more 'large_alloc' performed in lib_jpeg by this change). See also bug 16769, comment #81 (https://bugzilla.mozilla.org/show_bug.cgi?id=16769#c81)
Attachment #276521 - Flags: review?(pavlov)
Comment on attachment 276521 [details] [diff] [review] Patch to remove jpeg scanline (and a memcpy) Clever.
Attachment #276521 - Flags: superreview?(tor) → superreview+
mozilla/modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp 1.75 mozilla/modules/libpr0n/decoders/jpeg/nsJPEGDecoder.h 1.27
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M8
Version: unspecified → Trunk
Thanks! Green tree's, and current nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082618 Minefield/3.0a8pre) working fine.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.