0
\$\begingroup\$

I'm wondering what is more performance friendly:

1) Rendering a texture (in a seperate RenderTarget2D) and reuse it. (That will use multiple spriteBatch.End() / spriteBatch.End() calls, every drawing cycle)


2) Rerendering the texture multiple times (directly on the default rendertarget), but using only a single spriteBtach Begin/End call.

I think it is pending on how many times I'm going to redraw that texture, but calling spriteBatch.End() / spriteBatch.End() is taking really much performance...

So what should I use, when the redrawing count is pending on the user?

\$\endgroup\$
  • 2
    \$\begingroup\$ Why don't you try and measure? \$\endgroup\$ – Vaillancourt Oct 22 '16 at 17:16
  • 1
    \$\begingroup\$ I'm asking because I don't have time to measure/fiddling arround and I'm sure that the information will help others in the future! \$\endgroup\$ – TheRealVira Oct 22 '16 at 17:23
  • 1
    \$\begingroup\$ The core issues with performance related questions is that 1) we don't have the whole picture, so it's hard to give a good answer, and 2) it's not solving an issue that you actually have, it trying to maybe solve an issue that you'll maybe have, i.e. it's premature optimization. \$\endgroup\$ – Vaillancourt Oct 22 '16 at 18:45
  • \$\begingroup\$ @AlexandreVaillancourt agreed. It turned out that it was more a lack of understanding the way spriteBatch worked than an actual performance issue. \$\endgroup\$ – Felsir Oct 22 '16 at 19:01
  • \$\begingroup\$ @Felsir Yes, good job on this issue :) \$\endgroup\$ – Vaillancourt Oct 22 '16 at 19:02
0
\$\begingroup\$

The spriteBatch tries to be as efficient as possible. A spriteBatch is most efficient rendering the same (source)texture over and over. Since this means the GPU doesn't need to receive new texture information (which is the most expensive part of the sprite drawing operation. This is the reason most games pack textures into a texture or sprite atlas.

So in your game, if you can use 1 texture and 1 spriteBatch, that will be the most efficient way of drawing things to the default rendertarget.

//Draw 100 sprites very fast.
spriteBatch.Begin();
for(int i=0;i<100;i++)
{
   spriteBatch.Draw(myTexture, new Vector2(i*10,i*2), Color.White);
}
spriteBatch.End();

A 2D sprite is secretly a 3D plane- as today's GPUs draw 3D triangles. Thus a spriteBatch has a lot of parameters that simply convert your 2D coordinates to the 3D system. The spriteBatch.Draw() method has a lot of parameters to set the position, scale and rotation of the sprite. See this answer about spriteBatch.Draw overloads.

//Draw 100 sprites very fast, each one rotated and scaled.
spriteBatch.Begin();
for(int i=0;i<100;i++)
{
    spriteBatch.Draw (myTexture, new Vector2(i*10,i*2), null, Color.White, (float)Math.PI/(float)i, new Vector2(myTexture.Width/2,myTexture.Height/2), (float)i/100f, SpriteEffects.None, 0);
}
spriteBatch.End();
\$\endgroup\$
  • \$\begingroup\$ The second one doesn't use rendertargets - it's just going to draw on the default one right away! (But it does therefore rerender the texture several times.) \$\endgroup\$ – TheRealVira Oct 22 '16 at 17:37
  • \$\begingroup\$ Then I don't understand the issue? If you can do without rendertargets, then what is the problem? \$\endgroup\$ – Felsir Oct 22 '16 at 17:40
  • \$\begingroup\$ The issue isn't using rendertargets... The question is if I should use more rendertargets and spritebatch calls or rendering the texture multiple times and using only a single spritebatch call, when focusing on performance. \$\endgroup\$ – TheRealVira Oct 22 '16 at 17:46
  • 1
    \$\begingroup\$ A single spritebatch is likely to be faster. Are the textures you're drawing the same? And why would you consider the rendertarget scenario- what do you hope to achieve in it that may be faster than a single spritebatch? Note that the speed of a spritebatch also depends on how many different textures are used. \$\endgroup\$ – Felsir Oct 22 '16 at 17:55
  • \$\begingroup\$ Yes the textures are the same, but the position/rotation/scale is changing. Therefore I thought it would be smart to not redrawing it but rather save it in a rendertarget which than would be redrawn. Now thinking about it I don't have a choice? Because I cannot change the rotation/scale without it being in a rendertarget... \$\endgroup\$ – TheRealVira Oct 22 '16 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.