Quick sf::RenderTexture question

[NGM88]

I'm confused about something: If I'm drawing everything into sf::RenderTexture first, do I still need to batch for performance (like minimizing state changes) or does it not matter? I thought it did, but now some source is telling me that it doesn't matter because it's pre-rendering.

[eXpl0it3r]

A render texture is conceptually nothing else than an off-screen "window" you render to.
Rendering to the render texture should still be done carefully if performance is important. However once it's on the RT, you don't need to think about the render objects anymore, you already have them rendered into a texture.

[FRex]

If you render into it every frame or often then you should care about performance (within reason) but if you do it just once at start, level load, whatever and never again then just using its sf::Texture is cheap.

[NGM88]

I'm rendering into it every frame with 2 different textures and text with differing sizes/colors so I batch it as if I was batching for opengl state changes like so:

draw texture 1 for each open panel
draw text font 1 size 1 color 1 for each open panel
draw text font 1 size 2 color 1 for each open panel
draw text font 1 size 2 color 2  (so on and on for all differently colored/sized text)
draw texture 2 for each open panel (this has to be on top of text)

It would be so convenient to have each panel draw its own texture1, texts, and texture2; but if the cost of texture switching is the same as actual rendering, then I don't even have to bother testing this way because it's just too many texture changes it would definitely kill performance.

[Nexus]

but if the cost of texture switching is the same as actual rendering, then I don't even have to bother testing this way because it's just too many texture changes it would definitely kill performance.

How many switches are we talking about here? 2 different textures per frame, switched a few times is nothing.

To imagine that, look at any 3D game with a reasonably complex scene, and try to estimate how many different surface textures you see on the terrain, models, and UI. Even if some of them share an actual hardware texture, you can still do a lot.

In the end, just run a test to see if it's killing performance. It's hard to estimate the impact without knowing the specifics, but I would not optimize prematurely if it makes your application considerably more complex.

[NGM88]

To imagine that, look at any 3D game with a reasonably complex scene, and try to estimate how many different surface textures you see on the terrain, models, and UI. Even if some of them share an actual hardware texture, you can still do a lot.

In the end, just run a test to see if it's killing performance. It's hard to estimate the impact without knowing the specifics, but I would not optimize prematurely if it makes your application considerably more complex.

As far as I know, a professionally-made game like that would use texture arrays and have the entire scene be drawn in a single draw call, but that's not really something I know much about.

I usually see advice like "don't go over 10 draw calls if you're making a mobile game" online. If I stop batching now, the UI alone will have up to 10 texture changes along with all the font / text state changes.
I feel like I can save a ton time if I prepare my classes to batch / group stuff properly while I'm still coding.

[Nexus]

As mentioned: if you think it's an optimization to consider, especially because it comes at a price (code complexity), you should benchmark it and not base your decision on random vague statements like "don't go over 10 draw calls".

You don't need to finish your project until you can benchmark. It's very easy to simulate the same number of draw calls or texture switches with a sample application -- you don't need logic, UI or anything for this. And particularly benchmark it on your target platform, mobile and desktop hardwares vary a lot.

[NGM88]

Points well taken. Thank you very much for the replies.