Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Using SFML should I care about texture binds?  (Read 2232 times)

0 Members and 1 Guest are viewing this topic.


  • Newbie
  • *
  • Posts: 17
    • View Profile
Using SFML should I care about texture binds?
« on: April 21, 2021, 02:38:40 pm »
Hey everyone,

there's this one thing I never really understood: In how far do I need to manage texture binds? I'm using SFML out of the box, mostly just window, sprite and texture classes (sometimes VertexArrays).

Are all textures bound that are loaded as texture? Or only those bound to a sprite? Or only those which have been drawn at least once? What if I bind 30 gb worth of texture data? Are they loaded and bound one after the other? Will it just crash? Will it miss rendercalls? Render only the textures that can be stored? Will it simply take 3 seconds to render a single frame?
Should I unload every texture that is not needed asap?
Should I build texture atlases even though I dont use tilesets?
Are there texture binds happening for off screen sprites? What for partial offscreen Sprites? (Imagine a 20.000*20.000 image, will it actually bind and render the whole thing or only the pixels inside the view?)


  • SFML Team
  • Hero Member
  • *****
  • Posts: 10936
    • View Profile
    • development blog
    • Email
Re: Using SFML should I care about texture binds?
« Reply #1 on: April 21, 2021, 05:52:27 pm »
If you use pure-SFML you don't really have to think about binds in that way, as SFML will handle it transparently.

When drawing a VertexArray you need to pass the wanted texture as RenderState to the draw function.
I can't really tell you how the number of textures or size of textures affect your application, best to create custom fitted benchmarks for the use case you intend and check whether it fits your perfromance goal.

Texture atlases are always recommended, because you can then batch more in one vertex array draw call and texture switches aren't necessarily free. Of course with 30GB of texture data, you can't fit that in one texture...

Your GPU won't allow you to have a 20000x20000 texture.
SFML won't display things that are outside the view, but they are still sent to the GPU, which then determines what is and isn't shown. So you do have to take care of what data is sent to the GPU to stay within the availalbe bandwidth.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
Dev Blog: https://duerrenberger.dev/blog/