Mem leak with ofImage using grabscreen

beginners
#1

Hello, beginner question…

I’m currently using ofImage.grabScreen to send a texture to ofxSyphon. I’m doing this on every update.

Using the Call Tree in Xcode Instruments, the glReadPixels that is called from grabScreen keeps the memory growing on every call. If you could, let me know if anything seems obvious in the code below…

tmpImg.grabScreen(grid["textureXoffset"].asInt(),grid["textureYoffset"].asInt() , syphontexture.getWidth(), syphontexture.getHeight());

syphontexture = tmpImg.getTextureReference();
individualTextureSyphonServer.publishTexture(&syphontexture);
tmpImg.clear();
syphontexture.clear();
#2

Sorry, to be a bit more clear…

This call on every draw()

tmpImg.grabScreen(0,0 , 455, 256);
tmpImg.clear();

shows the same runaway glReadPixels allocations… ‘Malloc 64 bytes’ grows and grows… Any help is super appreciated!!

#3

I’m not sure about the leak but you can def grab the screen to texture not using an ofImage and it will save you alot on footprint / frame rate since you are reading back to pixels (everything stays in the graphics card). try the texture screengrab example in examples/gl if you need a reference.

#4

the glReadPixels call is in libGL.dylib and that seems to call GeForceGL driver. At any rate, this problem looks like it might even be driver/hardware related. I’m on a macbook right now. who knows…

#5

Thanks Zach! I’ll try that now…

#6

actually the fastest would be to use an fbo, draw to it, then pass the fbo texture to syphon that way there’s no transfer at all from the graphics card -> ram which would be slow.

something like:

fbo.begin();
//draw
fbo.end();
individualTextureSyphonServer.publishTexture(&fbo.getTexture());
#7

FBO is really interesting. Thanks Arturo.