I have a simple draw loop with saveFrame.  The first frame is saved correctly but then the applet freezes and the applet has to be quit or killed from a terminal session.

void draw() {
 image(img, 0, 0);

 for (int i=0; i<numCars; i++)
   cars[i].move(random(-2,2),random(-2,2));
 
 if (makeMovie)
   saveFrame();

 println("framerate="+framerate);
}

Am I doing something obviously wrong?

The tif files are also huge!  Is it possible to save with a compressed format?

Thanks!

Owen

Thanks for the idea, uoou: when I make the number of cars 0, the saveFrame works fine!  It's even pretty fast.  

BTW: Here's the original applet without the frameSave() code:
http://backspaces.net/files/Roads/applet/

If I set the number of cars to 1, it still works!  Weirder and weirder.  Still pretty fast.

If I set the number of cars to 100, it just works .. but very, very slowly.  The simulation itself runs quite fast (6fps even with 15,000 cars) as you can see from running the applet.

So it looks like the problem has to do with the cars?  Or possibly with any significant change at all in the image?

BTW: I also found that this behavior/bug is also true with saveBytes .. I tried converting the image to jpg using a previously posted SaveJpg method, and it also worked with 1, 10, very slowly with 100 and so on.  Its a bit slower anyhow due to the additional computation.

Owen

import com.sun.image.codec.jpeg.*;

void SaveJpg(String fname){
 ByteArrayOutputStream out = new ByteArrayOutputStream();
 BufferedImage img = new BufferedImage(width, height, 2);
 img = (BufferedImage)createImage(width, height);
 loadPixels();
 for(int i = 0; i < width; i++) {
   for(int j = 0; j < height; j++) {
     int id = j*width+i;
     img.setRGB(i,j, pixels[id]);
   }
 }
 try{
   JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(out);
   encoder.encode(img);
 } catch(Exception e){System.out.println(e);}
 byte [] a = out.toByteArray();
 saveBytes(fname, a);
}

Works fine here too. Slightly slower than windows but that's all.

Looks like it's time to check obvious stuff like running out of disk space and that?

I forgot to mention: I'm using Processing 107 on Mac OS X.  Don't know if it matters though.

Owen

saveFrame is really slow on osx, because java file i/o seems to be complete crap with the apple java implementation (there's an 8:1 difference between a 2.66 ghz dell desktop and my 1.5 ghz powerbook). so that's probably part of the problem.

it sounds like there's some sort of interaction between how saveFrame() works and how the draw() method works that might be slowing things down further though.. wonder if this is related to the other threading issues.

Well, the problem seems to have evaporated, lord knows why!

I tried uoou's idea of using background(img) and everything started to work.  But just to check, I went back to image(img, 0, 0) .. and it worked too!

I am on a later Processing: 109, but don't know if that fixed it.

Anyway, case closed for now.

BTW: using the nifty contributed software SaveJpg makes quite a difference in overall size even tho a fps or too slower.  Quite nice.

as posted on the related thread:

i think this is probably related to another bug report that i could never confirm. so we'll track this issue here:
http://dev.processing.org/bugs/show_bug.cgi?id=189

if anyone can help me track this down with an example that consistently causes trouble, that'd be great. i'll close this thread so we can follow up using the bugs db.