I have some code that seems to take up about 30 - 50mb a second while running.
I ran it through valgrind at work (valgrind newb) and got tons of errors, most of them seem to be culminating in the actual sdl libraries. I was able to find one area where I was making a mistake. Not to say something else I am doing is wrong...just wanted to get any opinions on this code.

loop through a block of pixels and make them all green.



//Init code


Uint32* surfacePixelData;
Uint32 temppixel;

//on view load
pixel_surface = SDL_CreateRGBSurface(0,640,480,32,0,0,0,0);
temppixel = SDL_MapRGB(pixel_surface->format, 30,250 ,60);


This is the offending code - happens every frame

//Draw a block of pixels and test speed
if ( SDL_MUSTLOCK(pixel_surface) )
SDL_LockSurface(pixel_surface);
surfacePixelData = (Uint32*)pixel_surface->pixels;

///RESOUCE HOG
for(x = 0; x < 460; x++){
for( y = 0; y < 620; y++){

surfacePixelData[(640 * x) + y] = temppixel;
//SDL_RenderDrawPoint(thisRenderer, x, y);//really slow like 1fps
}
}
if ( SDL_MUSTLOCK(pixel_surface) )
SDL_UnlockSurface(pixel_surface);

pixel_texture = SDL_CreateTextureFromSurface( thisRenderer, pixel_surface );


SDL_SetRenderDrawColor(thisRenderer, 0, 250, 0, 255);
d.w = 640; d.h = 480;
d.x = 10; d.y = 10;
SDL_RenderCopy(thisRenderer, pixel_texture, NULL, &d);

SDL_RenderPresent(thisRenderer);




When this is commented out, my executable takes up 20mb as reported by task manger
When run executable size increases drastically to the point where I run out of memory.

Thank you

I don't know SDL, but I assume that [font="'Lucida Console"]SDL_CreateTextureFromSurface[/font] is creating a texture. I'd assume that you're responsible for destroying that texture via [font="'Lucida Console"]SDL_DestroyTexture[/font].

You also need to free (using SDL_FreeSurface) the surface you get from SDL_CreateRGBSurface.

Thank you so much for the quick responses, should I be freeing these surfaces/textures every frame?

I am freeing them all when I exit the program - should I move these up - into my onrender frame?

What I am doing currently:

//
void mainscreendestroy(){

...
SDL_FreeSurface( pixel_surface );
SDL_DestroyTexture( pixel_texture );
...

}


Thanks again

What you have at the moment is basically doing this:[source lang=cpp]//start game
//frame #1
pixel_texture = SDL_CreateTextureFromSurface( thisRenderer, pixel_surface ); //create #1
//frame #2
pixel_texture = SDL_CreateTextureFromSurface( thisRenderer, pixel_surface ); //create #2
//frame #3
pixel_texture = SDL_CreateTextureFromSurface( thisRenderer, pixel_surface ); //create #3
//end game
SDL_DestroyTexture( pixel_texture );//destroy #3[/source]Texture #1 and #2 are "leaked", as the pointers to those textures are overwritten with new pointers.

So yes, you should probably be destroying those textures every frame, if you're going to create them every frame.
Another solution would be to not create them in the first place though

Do you really just want to fill that area with a given colour? Have you considered SDL_RenderFillRect()?

The real answer depends on your high level goal here.

Side note: consider using named constants. Your code is really unclear as to what size you are using (the magic numbers 460, 620, 480, 640 all appear in your source). Creating WIDTH and HEIGHT constants, or using pixel_surface->w and pixel_surface->h, would help immensely. There also appears to be a mismatch between the X and Y constants between the loop variables and the inner expression. The names "x" and "y" are misleading, as "x" is actually iterating over each line of pixels, and y is iterating inside these lines.

So yes, you should probably be destroying those textures every frame, if you're going to create them every frame.
Another solution would be to not create them in the first place though

Thanks a billion, destroying these every frame cleared everything right up - and everything is back in line - thanks for the prompt responses.

@rip-off
Sound advice, I was just trying to quickly throw a block of pixels on the page and benchmark the speed I can get. I am working on a raytracer, so later on the pixels will have a little variety too them. Thanks for taking the time to chime in!