[SOLVED] Copying texture from rendertexture.

[killerloader]

I want to use one rendertexture multiple times to create different images (As i've found deleting and creating new render textures to create massive memory leaks)
Basically i want to copy the 'texture' data from the rendertexture into a new sf::Texture.
I saw that you could save a render texture's texture to file, and then load it again into a new texture, however this would be pretty inefficient for per-step events.

Sorry if there is a simple function for this, i did look for a few minutes, but found no 'completely obvious' functions that do this.
As RenderTexture.GetTexture() will change as the render-texture changes.
As i was writing this, i thought of doing:
sf::Texture TestTexture;
TestTexture = RenderTexture.GetTexture();
Would this copy the texture data? or would it also keep a pointer to the texture data. I don't exactly have time to test it right now, so, sorry for a seemingly stupid question which i should probably hold off until i test that code myself.

[Glocke]

Yes it does. A RenderTexture's getTexture() returns a const reference to the texture (so it is not compied). But calling the copy assignment or copy construction of sf::Texture, the entire texture is copied. Keep in mind, that this operation might be expensive.

Btw

sf::Texture TestTexture(RenderTexture.getTexture());

would be the call using the copy constructor.

/EDIT: I recomment using different instances of sf::RenderTexture instead one RenderTexture and copy to buffer-like Textures. Having multiple render textures might be faster because you don't need to copy the pixels and reupload it to the graphics card. But I'm not quite sure about those implementation details.

[killerloader]

Thankyou! sorry for the unorganised question haha.
I'm using it to create a 'map' of solids in my game. the textures only need to be created at the load time, or in edit mode when a solid is placed, so speed isn't a problem. I'm using it to remove blood/ effects from the top of solid objects.

I cannot use lots of rendertextures due to them not deallocating their memory after being destroyed.
I am already using lots of rendertextures for another system, but they can be reused.

This is solved.

[Glocke]

I cannot use lots of rendertextures due to them not deallocating their memory after being destroyed.

Where did you found that information? In general, a class shouldn't leak when its destructor was called correctly.

[killerloader]

Not certain, i just gave up on trying to get around it.
http://en.sfml-dev.org/forums/index.php?topic=17235.0
eXpl0it3r says in that article that "It has most likely to do with the infamous context leak or a leak in the GPU driver."

I havn't tested it since getting new GPU drivers, so that may just be the problem.

Basically i created a loop which created and destroyed render textures, and the ram kept going up.

[binary1248]

I cannot use lots of rendertextures due to them not deallocating their memory after being destroyed.

Where did you found that information? In general, a class shouldn't leak when its destructor was called correctly.

I think killerloader misinterpreted what was originally said. If they don't deallocate their memory after being destroyed then that would constitute a leak, even in the classical "everybody understands this" sense. The difference here is that we can't destroy any some contexts we create until right before the application ends due to operating system constraints, so this isn't the classical "leak" but more of a "we have no choice but to hold on to them until the end". Since RenderTextures each create their own context, creating many of them will create a lot of contexts as well, which, in some cases will not be able to be destroyed until the end of the application.

EDIT: Reworded to be more precise.

[Glocke]

Since RenderTextures each create their own context, creating many of them will create a lot of contexts as well, which will not be able to be destroyed until the end of the application.

Thanks for that information! So (re)using a limited pool of render textures might be useful.

[binary1248]

Additionally, what I described above is what SFML has to do due to operating system constraints. Depending on your driver, the driver might leak memory as well (this is a "real leak"). If you have applications that create and destroy a lot of contexts, such as how SFML does it, the driver will slowly leak out memory over time. My guess is that this scenario doesn't get tested that thoroughly by the vendors, so it is something we have to live with.

[killerloader]

Thankyou binary, that actually made a lot of sense!

Anyways, after learning that it creates memory issues, i've begun reusing rendertextures.
This question is for a similar reason, i don't want to have to create any more render textures than i already have, so i'd rather just use one and copy it into textures where i can.

I don't think my GPU was contributing to the majority of the leak anyways, so that should be fine.

[Gerard Wensink]

What does the function cost?
sf::Texture TestTexture(RenderTexture.getTexture());