Bug 120 : java.lang.OutOfMemoryError using get() and image() inside a tight loop
Last modified: 2010-06-05 09:23



Assigned To:

Attachment Type Created Size Actions

Description:   Opened: 2005-08-08 21:35
OS X 10.4.2 / Processing 0091
Here is the source to reproduce the error:

PImage tela;
int a;

void draw() {
tela = get();

Additional Comment #1 From fry 2005-08-10 08:20
i assume you mean get() and image() being used like copy and paste?

this code works fine for me. could you explain the bug?

or is it something about copying and pasting the code itself?
Additional Comment #2 From Dimitre 2005-08-10 11:47
Sorry, I was not clear. I mean get() and image()
I noticed that worked fine right now. I am pasting the entire code, so I think the error
appears after running it for some time (OutOfMemoryError appear in here after 2000
I don't know if it is relevant, but I am using an Wacom tablet, I've noticed Processing is
showing some tablet events
this error doesn't appear when executing it on OPENGL mode.

PImage tela;
int a;
float b = .5;

void setup() {
size (100,100,P3D);

void mouseDragged() {
b = mouseX / 100.0;

void draw() {
tela = get();
background (a++%2 *255);
translate (width/2,height/2,-b);
rotateZ(-(width/2-mouseX) / 290.0);
rotateY ((height/2-mouseY) / 140.0);
Additional Comment #3 From fry 2005-08-10 11:59
k, seems to be a bug in how P3D is handling images. the minimum code to
reproduce is just:

PImage tela;

void setup() {
size(100, 100, P3D);

void draw() {
tela = get();
image(tela, 0, 0);

i'm guessing there's some sort of error that it's asking for too much
memory to draw the image but will have to look into it. unfortunately it
might be a little nasty to track down since i don't know anything about
where it's dying.
Additional Comment #4 From fry 2005-08-11 09:22
after a bit of testing:

- disabling the get() or the call to image() will make it go away, so both are needed.

- tried setting tela to null at the end of draw, thinking that maybe the gc wasn't getting a
chance to clean up (tela is reassigned at the beginning of draw, but draw is inside a
synchronized block). and while that may have allowed things to run a little longer, it still
had trouble.

- the fact that it shows up only in P3D means we're leaking somewhere. so probably need to
run this using java prof or optimizeit and find out where objects are being held on to.
Additional Comment #5 From fry 2010-06-05 09:23
also works fine with P2D, which makes this especially confusing.