Bug 355 : look into memory use for images, figure out how to make sure images unloaded
Last modified: 2008-02-26 11:16



Assigned To:

Attachment Type Created Size Actions
example #1 from casey's student application/zip 2006-05-20 13:45 169.82 KB

Description:   Opened: 2006-05-20 13:44
too many images, or images that are too large can cause OutOfMemoryErrors.
usually this is because the author is attempting something ridiculous, but
we need to iron out exactly how this should be documented (whether in
loadImage or the FAQ) so that people can unload image data properly.

attached are two examples that were causing trouble with lots of image data.
Additional Comment #1 From fry 2006-05-20 13:45
example #1 from casey's student
Additional Comment #2 From fry 2007-10-23 14:08
can't reproduce with this example (at least not anymore), we may have fixed
things properly.
Additional Comment #3 From jcmunoz 2008-02-26 10:58
(In reply to comment #2)
> Additional Comment #2 From fry 2007-10-23 14:08 [reply] can't reproduce with
this example (at least not anymore), we may have fixedthings properly.

Trying to load 4 big images, causes a java.lang.OutOfMemoryError. This happends
with less images if you use more objects on the sketch. The dimensions of the test
images are 1203x800, 4894x800, 4699x800 and 5711x800.

PImage s1 = loadImage("1s.jpg");
PImage s2 = loadImage("2s.jpg");
PImage s3 = loadImage("3s.jpg");
PImage s4 = loadImage("4s.jpg");

I got a better response asigning null to the variables when I don't need them but the
dispose in Java isn't a synchronus process, you still have a change to get the

Increasing the java max mem to 256Mb helps to avoid the problem, but you have to
ask the web applet users to increase the memory for java on the control panel.

It should be an option to partially load images or store them in memory in a more
memory efficient way.
Additional Comment #4 From fry 2008-02-26 11:16
that's a different problem, and not something that we can really fix.

an image at the dimensions you specify is about 4 million pixels. each
pixel is 4 bytes of data (ARGB), meaning 16 MB for the image. depending on
the renderer, or whether you're tinting the image, you may need twice that
so that the original image, and a tinted (or cached, in the case of opengl)
version can be stored. so now you're at 32 MB or more for a single image.
depending on your RAM configuration, Java may give you 128 MB by default
(there's nothing we can control about that in the browser). so now you've
got 4 images at that size, and you need to do the same math for the size of
your drawing surface (perhaps doubling that for the zbuffer if you're in 3D).

you can file the issue you cite as an 'enhancement', but it's not a bug,