Is it safe to overwrite sf::Texture after calling render_texture.draw()?

[GetterSetter]

The problem: I have a set of textures, but they are not of the sf::Texture type. However, sometimes I need to set them to sf::RectangleShape and render them. The idea is as follows:

sf::RenderTexture rt;
rt.create(...);
rt.clear();
for(auto &texture:non_sfml_textures)
{
  sf::Texture t=convertion_function(texture);
  sf::RectangleShape rect;
  rect.setTexture(&t);

  //Setting position of rect, etc...

  rt.draw(rect);
}
rt.display();
 

Is it safe to do so? By 'safe' I mean that all the textures will be rendered correctly after calling rt.disaplay().

[eXpl0it3r]

No, textures have to exist for as long as you use them and a "use" counts until you call display().
For anything else, SFML doesn't provide any guarantees.

[GetterSetter]

Hm, what if put rt.display() inside the loop and don't clear rt? Does it have any side effects? From my perspective, it looks like all the rendered rectangles will just stack in the texture, and that's definitely what I want, but I'm not sure if it works as I expect. No, it doesn't work like this.
The problem is that I don't want to create a whole set of texture copies just to render them, because it requires a lot of memory.

[eXpl0it3r]

What other kind of textures do you have anyways?

Creating a texture on the fly isn't a cheap operation.
If it's an OpenGL texture, you could also just bind it, instead of creating a copy.

[GetterSetter]

I have tgui::Textures. Would you mind explaining to me, please, how I can use the bind function, because it's not clear from the documentation?

[eXpl0it3r]

If you have tgui::Texture can't you just call texture.getData().backendTexture->getInternalTexture() which should return the sf::Texture instance?

https://tgui.eu/documentation/latest-stable/classtgui_1_1Texture.html#a749d82057ff2ac73060ad1c6bbd8b970
https://tgui.eu/documentation/latest-stable/TextureData_8hpp_source.html
https://tgui.eu/documentation/latest-stable/classtgui_1_1BackendTextureSFML.html

[texus]

If you need a texture that you use for drawing in SFML and you also use for TGUI then I actually recommend loading it twice (once as sf::Texture and once as tgui::Texture), because TGUI makes no guarantees about how its texture is stored internally and whether it will be compatible with sf::Texture.

That said, you can get access to the internal SFML texture with the methods that eXpl0it3r mentioned:

const sf::Texture* pTex = &std::static_pointer_cast<tgui::BackendTextureSFML>(texture.getData()->backendTexture)->getInternalTexture();
rect.setTexture(pTex);

[GetterSetter]

Thank you, texus and eXpl0it3r! The only question I have now is whether we should use dynamic_pointer_cast instead of static_pointer_cast because we are performing a downcast.

[texus]

dynamic_pointer_cast will return a nullptr if the backend texture is of a different type, while static_pointer_cast assumes the type is correct and has undefined behavior if the backend texture is of a different type.

As long as you use the SFML_GRAPHICS backend, you can be certain that the backend texture always has type BackendTextureSFML, so the cast will always succeed and a static_pointer_cast is fine. Also, there is no point in using dynamic_pointer_cast if you aren't going to check whether the return value is a nullptr or not.

[GetterSetter]

Got it, thank you!