554971 - Creating thumbnails of local images using file API consumes enormous amounts of memory

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[markus]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)

I tried using your example from
https://developer.mozilla.org/en/Using_files_from_web_applications
to display a small thumbnail of the images the user is about to upload.

It works perfectly. However, the memory consumption renders this unusable. I selected 10 JPG images with a total of 34.9 MB. The images were scaled using max-width/height but I also tried resizing them using a canvas object.

After the images are read, Firefox consumes ten times the memory of the images:
http://www.abload.de/image.php?img=fileapi0mc5.png
(scale is 100 kBs, so 3600 is in fact 360 MB).

Reproducible: Always

Steps to Reproduce:
1. Copy the example from https://developer.mozilla.org/en/Using_files_from_web_applications
2. Select some images
3. View Firefox's memory consumption, e.g. in the Task Manager
Actual Results:  
Memory consumption of approx. ten times the images' size

Expected Results:  
Firefox should use less memory.

What is this memory needed for? I guess the image is first read into memory, then converted into a data-uri, maybe copied into the src-attribute of the img and displayed as an image. If I count this, there are only four copies at the image in total, assumed that every result is materialized.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

can you create a testcase and attach it using "Add an attachment"?

Comment 2

[Boris Zbarsky [:bzbarsky]]

> If I count this, there are only four copies at the image in total

If you're showing the images to the user, then there is also an in-memory copy of the decompressed image data (needed to paint the image).  Depending on your JPEG compression settings, this may be significantly larger than the original JPEG file.

Comment 3

[Boris Zbarsky [:bzbarsky]]

And more to the point, creating thumbnails by painting the images to a small canvas should work fine once the original image is garbage-collected....  Resizing them via CSS is the same as just sticking a large image on a page and resizing it with CSS.

Also note that the decoded data is discarded on a timer, depending on your available memory and such.

Comment 4

[markus]

Attachment: test case

This test case provides both an example for CSS and Canvas Resizing.

Comment 5

[markus]

> there is also an in-memory copy of the decompressed image data
Yepp, forgot about that one.

> should work fine once the original image is garbage-collected
Yes, it does. But the amount of memory consumed beforehand causes a lot of paging. 500 MB is not a problem at all if you are working with 4 GB+ of RAM, but think of e.g. netbooks. A lot of pages have to be paged out in order to provide this virtual memory, so the system is slowed down even after GC.

Comment 6

[dholdaway986]

Have observed this problem with a sideshow of a client-side gallery app. Have reproduced the problem using a single <img> tag into which jpeg image files are loaded from the local drive. 

Have created a test case which demos the consumption of memory. The demo shows the next image when you click on the image. Copy the test.html onto a local file system and create a folder in the same directory called "images" then copy jpg images in sub folder.   

Tested with files sized between 3-5M, if larger images (7M+) used then firebug reports 'Image corrupt or truncated: file.......' much more regularly.  

I can see the memory usage growing in the Windows Task Manager until the files fail to load and the browsers locks up. 

The test code work fine in other browsers i.e. Opera and Google Chrome

Comment 7

[dholdaway986]

Attachment: test case

Comment 8

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.