<vector> of ofTextures

Hi all,

I’m working on a project that captures and replays long image sequences. I have a working example that uses the simple approach of loading an image file into a texture, then drawing it on screen, every frame. On a fast mac the frame rate is sufficient, but on a slower machine i’m getting around 17fps which is too slow. And this is very inefficient.

You can see the code for this here:
https://github.com/robmint/skylight/blob/master/src/testApp.cpp
in the testApp::draw() function.

I want to use a circular texture buffer for use in image playback so that the next few frames are kept in memory for fast access, with more frames loaded from disk as needed. The sequences of images are long (can be > 3000 frames) so loading the whole sequence is not practical.

I have read the example using pointers here:
http://forum.openframeworks.cc/t/vector-with-oftexture-instances/5356/0

Here is my code with a hard wired vector index as a way of testing in preparation for working with n number of textures.

  
  
  
vector<ofTexture*>;  
ofImage loader;  
string file;  
  
texture.clear();  
texture.push_back(NULL);  
texture[0] = new ofTexture();  
loader.loadImage(file);  
texture[0]->allocate( loader.getWidth(), loader.getHeight(), imageTypeToGLType(loader.type) );				  
texture[0]->loadData( loader.getPixels(), loader.getWidth(), loader.getHeight(), imageTypeToGLType(loader.type) );  
  
texture[0]->draw(xpos, ypos, texture[0]->getWidth()*xscale, texture[0]->getHeight()*yscale );  
delete texture[0];  
  

This code works and gives about the same performance as before. Is this correct usage?

The installation runs for a couple of weeks so I also need to be careful not to leak memory over the life of the process.

Thanks
Rob

ofTexture handles GL pointers / dynamic graphics memory internally, so you don’t need to use vector<ofTexture*>. just vector.

furthermore, if you know that you will never need more than N frames, it makes more sense to just allocate them all in advance, then ofLoadImage into the texture as necessary. this will be faster than always doing reallocation (if i understand your question correctly).

Ah right beginning to get the picture. I’ve re-rewitten my code to use vector. This works. The push_back is initialising the element with the constructor, correct?

  
  
// types  
vector<ofTexture> texture;  
ofImage loader;  
string file;  
  
// clear vector of all elements  
texture.clear();  
// push new object into vector  
texture.push_back(ofTexture());  
  
loader.loadImage(file);  
texture[0].allocate( loader.getWidth(), loader.getHeight(), imageTypeToGLType(loader.type) );				  
texture[0].loadData( loader.getPixels(), loader.getWidth(), loader.getHeight(), imageTypeToGLType(loader.type) );  
texture[0].draw(xpos, ypos, texture[0].getWidth()*xscale, texture[0].getHeight()*yscale );  
  

Rob

push_back() just enlarges the size by one element (basically). what kyle means is to allocate the memory with reserve() at the beginning. see http://arturocastro.net/blog/2011/10/28/stl::vector/

That link looks very helpful. Great!

Rob

actually, i wasn’t thinking of reserve(). reserve() is most useful when you’re dealing with a large vector that is going to grow and shrink very fast, and you have a good idea of how big it could possibly get.

in this case, he’s talking about using a circular buffer to store images that are all the same size. this means you can actually do a resize() and allocate them all in advance.

i would write a little code to illustrate, but i think the better solution is to just use this addon from james george https://github.com/Flightphase/ofxImageSequence/

Thanks, I did look at the code for James’ addon - I was originally using his addon as is. Then I began adapting to fit my needs a bit better - i need to load in images on the fly. It was at that point where I began to wonder about the vector<ofTexture*> as James does it, vs vector. I’ll go back and look at it again in light of what I learned from Arturo’s article.

Rob