SFML doesn't clarify the guarantee or lack thereof for random bits when creating render-textures / textures

[dogunbound]

SFML doesn't clarify the guarantee or lack thereof for random bits when creating render-textures/textures

Whenever you create a render texture or a texture, SFML currently does not guarantee that the underlying texture is completely empty. What I have noticed is that the 3 different major GPU manufacturers may have different results when simply creating a new render texture or texture.

Intel Arc will not clear the GPU of old data, and therein require the user to do a clear before manipulating the texture.
Nvidea/AMD will automatically clear the old data on the render texture/texture.

Your environment

• Arch Linux
• 2.6.0
• GCC 13.1.1

Steps to reproduce

Might be a bit expensive to go and get 3 GPUs from all of the different manufacturers to test it, but you'd essentially test it with code that makes a new render-texture for each frame without calling clear (forcing the chance of random bits to show up raised) and draw the same thing that render-texture. It might also be good to have this thing you are drawing onto the screen move around. Do it with all three manufacturers, and see the result.

Expected behavior

All GPUs have the same behavior OR documentation stating that render-texture / texture creation is not guaranteed to have cleared the old bits of data still on VRAM.

Actual behavior

Different manufacturers have different behavior AND documentation does not state that this is a potential problem.

[eXpl0it3r]

I've added the following in #2994, is that sufficient @dogunbound?

After creation, the contents of the render-texture is undefined, call RenderTexture::clear first to ensure a single color fill

[ChrisThrasher]

Closed by #2994