Honestly my experiments with threaded dropping to disk didn't succeed in any performance improvements. (At least on Windows 8). Basically when you run on different threads, your files are technically saved from different threads, but then the Operating System freezes for few milliseconds to flush disk buffers. And that freeze stops ALL the threads of your sketch, so eventually you get frame-rate drop and NON-smooth animation.
Many things when saving your graphics boild down to simple math:
On average my harddrive can write about 30Mb of data per second.
An PImage of 1200x720 would take about 3,456,000 bytes (3.5Mb), so you're limited to being able to write to disk 9 frames per second.
If you compress them to JPG or PNG or TGA, then your CPU time becomes the bottleneck: at 30fps (which is kinda lowest frame rate to have your animation smooth) you have 33 Milliseconds for each frame (33 millis x 30 frame = 1000 millis). I think TGA compression is the fastest and it would take probably 15milliseconds. So you have 18 millis left for calculating your graphics, drawing your graphics and writing to disk or whatever else your sketch is doing. 18 millis for that is not much.
To compressing Images into JPG / PNG Processing uses java image IO. Which seems to be pretty slow. (I guess because it's written in Java but not C). I think that compression of an image into JPG which is done under the hood by saveFrame() may take up to 100 milliseconds.
This becomes a big problem when saving high-framerate image data (and this is also explains the reason why when you add
saveImage()
or
saveFrame()
to your sketch it becomes VERY SLOW).
If you want to calculate how much time is spent on saveFrame() call, just put something like this:
- int saveStartTime = millis();
- saveFrame(....);
- int millisecondsElapsedForSaving = millis() - saveStartTime;
- println("Time elapsed on saving frame: " + millisecondsElapsedForSaving + " millis");
And once you have the time, you can do your math yourself.
I spend a day playing around with processing and trying to find a way to save quickly real-time video and was bounded by limitations at all sides:
- disk write speed
- CPU time
- available RAM
The one solution which would seem to me would work with processing directly is if you connect 4 SSD drives to your computer and split your screen into 4 parts and write each of them on the each of SSD drives separately. After that you can try to glue together your quadrants into a one high-resolution high-frame-rate image. But I guess this not attainable for normal people.
Another option (if you have a lot of RAM, ie. 16GB) is to store images in memory (not flushing them to disk), until your memory allows:
So:
16 GB ~= 16 000 Mb
16 000 Mb / 3.5Mb (1200x720 PImage) = 4 571 frames
if you run at 30fps, then you will be able to save 152 seconds of your sketch frames. Which is almost 2.5 minutes.
This probably would be the easiest option.
To implement it all you have to do: instead of saveFrame() , just make a copy of pixels[] array of your sketch to memory. Then when some key is pressed, you should stop animating and just flush all thouse 4571 images to hard-disk.
Also, I've heard of the tool called
http://www.ezvid.com which is a screen recorder aimed at gamers. I haven't tried recording games or sketches with it, but I guess if they aim at gamers recording their gameplay, I guess they should have optimized the app for high-framerate stuff. Maybe they have some recording core written in C++ or uses some optimized way of accessing hard-drive. You may want to try it. Though beware that during installation it offers you a lot of "toolbars" so be sure to decline toolbar offerings.
