Closed Bug 116257 Opened 23 years ago Closed 22 years ago

Loading a 150kb png image bloats 15-17mb

Categories

(Core :: Graphics: ImageLib, defect)

x86
Windows NT
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 51028
Future

People

(Reporter: naving, Assigned: pavlov)

References

Details

(Keywords: memory-footprint)

Attachments

(3 files)

I will attach the image. Also this image is the mailnews dependency map posted by alecf in n.p.m.mail-news (if you sort by lines you should see it in your thread-pane). Also this has nothing to do w/ mailnews code because if I save it locally and drag and drop it to a browser window it bloats by same amount - 15-17mb. I am filing it on you, I will also reasearch a bit, but feel free to assign it to the right owner.
Attached image image (deleted) —
image that causes bloat.
Keywords: footprint
naving, you should file this under the "Browser" product with a component of "ImageLib"
Attached file top callsite report (deleted) —
top callsite report shows that all the allocation is being done in imglib, as expected.
Attached file stack trace for top callsite (deleted) —
changing component and the owner
Assignee: mscott → pavlov
Component: Mail Back End → ImageLib
Product: MailNews → Browser
QA Contact: esther → tpreston
Keywords: mailtrack
Isn't this to be expected? The image is over 7000 pixels wide. If imglib is going to display something, it probably has to be converted internally to a Windows DIB or DDB first. Depending on the color depth, the DIB/DDB is going to be 4MB (at 1 byte/pixel) up to 18MB (4 bytes/pixel).
IE takes like 5-6mb, could be image resolution but I wasn't very sure.
I don't know enough about imglib, so I'm guessing here. Maybe Mozilla's imglib isn't using the optimal color depth for the DIB/DDB? The actual PNG file is apparently 4bpp, so IE's use of 5-6MB sounds about right. Maybe Mozilla is promoting the image to 32bpp (due to transparency?).
Target Milestone: --- → Future
Blocks: 124608
I don't see the bug here. The image is 7175x743 pixels large. Every image gets decoded using 4 bytes per pixel (Mac) or 3 bytes per pixel (all others). so for PC, the expected memory usage (just for the image data itself) is 15,993,075 bytes. (on a Mac: 21,324,100 bytes).
John, yes, this does sound like a dupe (PNG case) of bug 51028.
does anyone notices the performance problems scrolling the image? on two NT boxes that i tested, to scroll right the attached png image takes forever (~1 minute!) with CPU at 100%. this doesn't happen on another box with Win98
*** Bug 164871 has been marked as a duplicate of this bug. ***
Yes, essentially the same issue as Bug 51028. We expand all images to 24 bits per pix minimum, even if they are 8 bit. 3 - 4x memory usage than need be in those cases. *** This bug has been marked as a duplicate of 51028 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: