Hello,

I have finished writing a "photomaton" application for an exhibition, but while running it for testing, I eventually found that the application never stop eating RAM, and cannot run for a long time.

Basically what the application does is loading 4 images into textures, applying some GLSL effects to them, then "additive crossfade" the 2 resulting textures (using GLSL too). Once the crossfade is over, the 4 textures are initialized and renewed with 4 new images. I double checked the code so that any GLTextureFilter or GLTexture are really replaced by new ones during the process.

So after I managed to see the problem, I wandered here and on the GLGraphics sites to see if there was any trace of workaround for this type of memory problem. I found one post with a very simple script that creates the problem:
[can't post link, arrg]

I work on linux (ubuntu 9.10), and have several computer so I tested this with the following configuration (always ubuntu 9.10, processing 1.0.9, and proprietary ATI or Nvidia drivers)
- AMD (sempron ?) 2Ghz / ATI Mobility radeon HD 3450 / 64 bits OS
- AMD (sempron ?) 2Ghz / ATI Mobility radeon HD 3450 / 32 bits OS
- Intel Core2duo 2.4 / Nvidia Gforce 8600M GT / 64 bits OS

So I'm currently looking for infos, does this behavior is related to the GLGraphics library ? Or is it a more general Processing issue ?
As I looked deeper in the GLGraphics API I noticed the " clear(int) " methods and I tried to use this to really "initialize" the texture each time it changes, with no luck.

My application uses large images, but should not use more than 4 of them (into textures) at the same time, so even if they took 10 mo each, that my filters created 8 textures for each image, that would be : (4x10)x8 = 320 Mo maximum. There is room in ram, but it seems it constantly adds the texture and never unload them. As the application is meant to run at least 6 hours a day, it's a concern and I'm stuck.

Thanks for any help.

dF

You need a debugger / memory analyzer.

This is the first link I found, searching for "Java memory analyzer".

I don't know how to use it, but I suggest you look into this or something similar.

http://www.eclipse.org/mat/

The Eclipse Memory Analyzer is a fast and feature-rich Java heap analyzer that helps you find memory leaks and reduce memory consumption.

Use the Memory Analyzer to analyze productive heap dumps with hundreds of millions of objects, quickly calculate the retained sizes of objects, see who is preventing the Garbage Collector from collecting objects, run a report to automatically extract leak suspects.

I know that the code you posted was simply to trigger the problem and I am not familiar with the library you are using but since the draw() method executes about ~60 times per second you are loading an image and creating a GL texture 3 times a second would it not be better to create all 4 textures in setup and then flip when needed in draw.

Hi subpixel

I can only go off the code presented in this thread and it is quite clear that the following instructions are being executed every 20th frame.

Code:

   img = loadImage("img.jpg"); //replace by any 80 Kb jpg image
   tex = new GLTexture(this);    // tried to re-init the texture
   tex.putPixelsIntoTexture(img);
 

I assume that defred has used the same approach in his code.

Assuming all the images are the same size I suggest that defred create the textures in setup() and then simply push the images into the texture in draw() with
Code:

tex.putPixelsIntoTexture(img); 

and see if it makes a difference.

Detials of this library can be found here and make interesting reading, I will have to look at this library more closly mmm...

Quote:

Tried that, no changes. It looks more like the images data is accumulating (is that english oO). I'm currently moving my app over to an eclipse environnement to find tools to investigate the issue. I feel I'm becoming "one of them" using this monstruous eclipse software... I'm a designer for one's sake !
I'll keep you posted.

dF

@subpixel :
you're right, but my project is really not a big deal, And should be stable for a day long, even with the "simplified handling of things" of processing.

After further testing (including test on winXP with same library, then with the OPENGL render) it appears that the problem is somewhere around textures objects. The more you create, update, filter, textures objects, the faster the memory drops, even if I "clean" textures by using some tex.clear(int) methods.
It's worst noting that the problem occurs when using either OPENGL or the GLgraphics renderer.

Not using textures at all (non-sense with this library made for such operations) makes the memory problem disappear, and the smooth "GLSL blur filtered multilayered" images too :/ .

I'm thinking of "how to get rid of textures, still have nice images and low cpu usage ?".

dF

Expecting a program that hasn't undergone extensive testing to run for hours, let alone a day, is perhaps a little naive. A "small" memory leak problem could kill it unexpectedly at any moment, and depending on what resources and so on it uses (network access, file access, database access), there are thousands of things that can go wrong.

You hope they don't, but Murphy's Law says something bad will happen... How you deal with it is the difference between a hiccough and disaster!

@Subpixel : let's make something clear, I don't expect the app to run perfectly tomorrow, I AM in the process of testing it to find a suitable solutions on stability, ressources consumption, etc...
The exhibition is in may, I don't panic, I don't blame processing or libs, I'm learning while doing, but I have time. I don't think the app is too demanding, get video flux to capture portraits, while displaying funny mix on second monitor (yes with GLSL script and GLSL nice filters). And yes I AM a little naive, and I like it ;p
(btw, I also have to build the "photomaton" physical box too ! PowerTools here I am !)

@Quark, ok I will try more stricts methods and make sure I do get rid of useless references, but for now after tweaking a little the script I posted, I found that the memory usage expands only when texture manipulations occurs, event simple ones like creation or update. I might be missing some points about referencing object and opengl. Anyway I'll look at it.

@ac : thanks for the hint, the link and of course the library (and its GSVideo sister). Right now I can't test it, but as soon as I'm back on this I will study the thing.

Thanks all for hints and ideas you bring.

dF