Thread: OpenGL memory increases

  1. #1
    Registered User
    Join Date
    Feb 2006
    Location
    Leiden, NL
    Posts
    12

    Unhappy OpenGL memory increases

    Hi,

    i have a large file which holds a lot of coordinates of lines. These line form a map. In my main program I have a boolean array which keep track of the lines which need to be highlighted. I'm using OpgenGL for displaying the map, following the lighthouse3d tutorial.

    The display list is created as follows:

    Code:
    GLuint createDL() {
    	GLuint mapDL;
    	mapDL = glGenLists(1); 	// Create the id for the list
    	glNewList(mapDL,GL_COMPILE); 	// start list
    	GLpaintShapeFile();
    	renderMap();	// call the function that contains 
    	                  // the rendering commands
    	glEndList(); 	// endList
    	return(mapDL);
    }
    The function GLpaintShapeFile reads the file with lines and calss the function which draws those lines:
    Code:
    void GLpaintShapeFile(){
    	for(int i = 0; i < nEntities; i++ )
    	{
    		SHPObject	*psShape;
    		psShape = SHPReadObject( hSHP, i );
    //first paint all the non-highlighted parts
    		GLpaintShape(psShape, psShape->nVertices, i, 1);	
    		SHPDestroyObject( psShape );
    	}
    	for(i = 0; i < nEntities; i++ )
    	{
    		SHPObject	*psShape;
    		psShape = SHPReadObject( hSHP, i );
    //then, paint all the highlighted parts
    		GLpaintShape(psShape, psShape->nVertices, i, 2);	
    		SHPDestroyObject( psShape );
    	}
    The function which actually draws them is:

    Code:
    void GLpaintShape(SHPObject *psShape, int n, int i, int k){
    	if(n>0){
    		if(psShape->nSHPType==3){
    			if ((highlight[i]==false)&&(k==1)){
    				glColor3f(1,1,1);
    				for(int j=1;j<n;j++){
    					glBegin(GL_LINES);
    					glVertex2f(psShape->padfX[j-1],psShape->padfY[j-1]);
    					glVertex2f(psShape->padfX[j],psShape->padfY[j]);
    				}
    			}
    			else if((highlight[i]==true)&&(k==2)){
    				glColor3f(0,1,0);
    				for(int j=1;j<n;j++){
    					glBegin(GL_LINES);
    					glVertex2f(psShape->padfX[j-1],psShape->padfY[j-1]);
    					glVertex2f(psShape->padfX[j],psShape->padfY[j]);
    				}
    			}
    		}
    	}
    }
    The problem is: after the function GLpaintShapeFile() is called, there is about 10 MB of memory which is being used but never freed. So everytime there is a change and the map needs to be changed, my program uses 10 MB extra. I know I probably have to free memory somewhere (from the outdated map) before drawing the new map, but where? What has to be deleted?

    I hope someone can help me.

    P.S. Sorry for the large amount of code, but I'm using non-standard object. Therefor I've included it to make it more clear. I hope.

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    In short, I wouldn't worry about it. Your calls to read objects are being matched by calls to destroy objects, so the code you've shown does not actually leak.

    A longer answer (which explains what you're observing) follows

    Presumably SHPReadObject() and SHPDestroyObject() are allocating and releasing dynamic memory, among other things.

    One possible strategy for managing dynamic memory is for every allocation to obtain it from the OS, and every deallocation to return it to the OS. That is what you're expecting. Unfortunately, the process of getting memory from the OS (or returning it) is somewhat expensive and time consuming. So C/C++ libraries tend to use an alternative strategy: they manage a cache, and only grab memory from the OS or return it when really necessary. The behaviour of the cache means that the program consumes a little more memory (what the program needs, plus management of the cache) but the result is a faster program. One side effect of a cache is that the program can (when, for example, viewed from the windows task manager) appear to be hanging on to memory. This is not a leak: it is a trade-off between program speed and memory usage. The smarter C/C++ libraries will sometimes detect if the system is low on memory, and release memory back to the OS if needed.

    Incidentally, unrelated to your problem, but I suspect this might be a more efficient way to implement your GLpaintShapeFile() function;
    Code:
    void GLpaintShapeFile(){
    	for(int i = 0; i < nEntities; ++i )
    	{
    		SHPObject	*psShape;
    		psShape = SHPReadObject( hSHP, i );
                    for (int j = 1; j < 3; ++j)
    		    GLpaintShape(psShape, psShape->nVertices, i, j);	
    		SHPDestroyObject( psShape );
    	}
    }
    because, at a guess reading every object twice would be somewhat slow .....

  3. #3
    Registered User
    Join Date
    Feb 2006
    Location
    Leiden, NL
    Posts
    12

    glDeleteLists

    Thnx for the reply and your explanaition...

    I think I found out what my problem is. When the map has to be redrawn, I didn't delete the old display list first. Now, before creating the list, I call the glDeleteLists function. Now the extra memory isn't increasing, but my program stops responding further down the road. Have to figure out what's happening there, but so far, so good.

    Thnx again

  4. #4
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    Don't read the files as part of your display list!!

    Just read them once (before creating the display list) keep them in memory and make your display list render them. reading the file everytime you render will take wayyyyyy too long.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 7
    Last Post: 02-06-2009, 12:27 PM
  2. Copying memory, pointers and the like.
    By psychopath in forum C++ Programming
    Replies: 34
    Last Post: 12-12-2006, 01:37 PM
  3. Replies: 28
    Last Post: 07-16-2006, 11:35 PM
  4. Shared Memory - shmget questions
    By hendler in forum C Programming
    Replies: 1
    Last Post: 11-29-2005, 02:15 AM
  5. Linking OpenGL in Dev-C++
    By linkofazeroth in forum Game Programming
    Replies: 4
    Last Post: 09-13-2005, 10:17 AM