How expensive are sprites?

[dshenoy]

Dear Community,

I’m running my code on a mac osx machine.  I’m trying to understand the details behind sprites.  I wanted to know the following:

• Are sprites stored on the GPU (ie all he details about the graphical icon)?
• How do you judge whether you have too many sprites?
• Is there context switching that takes place with spite data stored on the GPU?  Is it switching in and out from the CPU if there isn’t enough capacity?

Please let me know if there are links on the internals for SFML sprites if they exist (advanced info)

Thanking you in advance.

[eXpl0it3r]

Sprite itself is a lightweight class and doesn't directly have an impact on performance.

The texture it uses and the draw calls made by the sprite is what needs to be considered.

If you use multiple textures, then you'll be paying the price of a texture context switch, which can be okay, but can also quickly add up. As such the general recommendation is to use texture atlases (e.g. tile maps), which then lets you reuse the same texture, but with a different texture rect.

Draw calls are slow and one of the most common causes for rendering performance issues (with SFML).
This should usually be fine for a few hundred sprites, if you get into the thousands, you should really reconsider your options. The general recommendation here is to switch to vertex array or vertex buffer, which allows you to render a whole "mesh" of vertices in a single draw call.

The best source (pun intended) for these questions is the source code: https://github.com/SFML/SFML/blob/2.6.x/src/SFML/Graphics/Sprite.cpp

Are sprites stored on the GPU (ie all he details about the graphical icon)?

No, sprites reside entirely on the CPU/RAM side. Textures however are stored in VRAM (which is why copying textures is expensive, as you first have to move it from VRAM to RAM and then back to VRAM).

How do you judge whether you have too many sprites?

There isn't a specific rule. Usually things become noticeable if your game (not some artificial "benchmark") doesn't manage to get a reasonable framerate (60-200fps).

Is there context switching that takes place with spite data stored on the GPU?  Is it switching in and out from the CPU if there isn’t enough capacity?

[/quote]
Sprites are lightweight objects. You can use them even as temporaries and recreate them every frame, but just because you can, doesn't mean it's really recommended.

[dshenoy]

@eXpl0it3r - Thank you ver much.  I’ll dig deeper into vertex arrays or buffers as you mentioned.

[Hapax]

I'd just like to add that if you still want to use sprites and the interface that comes with it, you'll need to use some sort of "sprite batcher". This is in effect just a vertex array but compiles the sprites into a vertex array automatically.

For example, this sprite batcher on the Wiki:
https://github.com/SFML/SFML/wiki/Source%3A-Simple-Sprite-Batcher
allows you to pass the normal (and lightweight) sf::Sprites to it and it batches them into a vertex array automatically. Using this will almost definitely improve performance over just using sf::Sprites directly. From tests, it seems to be usually twice the speed.

Slightly better - and with better performance - would be a batcher that is designed to not build everything from scratch every frame so you can pass an sf::Sprite and it would change just that part.
The Sprite Batch that is a part of Selba Ward (although it can be used separately from the rest of the collection) can do just that along with allowing you to apply sf::Sprite properties directly to it so you don't even need separate sf::Sprites! You can still use separate sf::Sprites if you'd prefer, of course!

Note: a single vertex array requires the use of a single texture so these sprite batchers also have that requirement.