Surface Blitting Cost

Hi guys, I was wondering if anyone knows how expensive exactly is blitting a
surface onto another? I imagine it would be essentially copying pixel arrays
from one surface to another, which would make it roughly O(N) where N is the
number of pixels, but I dont know the constant factors and general real world
performance…

Reason I ask is, I am in am doing an app where several images have to be
combined together, rotated, then finally placed onto the screen. I have sprite
sheets of the items I have to splice, and will be using OpenGL to rotate the
final image. So I’m wondering if its cheaper to load all of them into OpenGL as
textures (each sprite, not the sheet entirely) or use SDL to pick pieces of the
sheet out, blit them together, and then pass the blitted surface onto OpenGL as
a texture (which means I’d have to create one every frame since the image is
constantly changing) and only then rotate it.

It seems the latter would be awfully slow because of the blitting and texture
creation. But the sprite sheets are large, thus shoving them into memory in and
out is a hassle.

What do you guys think? Any input is appreciated, thanks in advance!

Reason I ask is, I am in am doing an app where several images have to be
combined together, rotated, then finally placed onto the screen. I have sprite
sheets of the items I have to splice, and will be using OpenGL to rotate the
final image. So I’m wondering if its cheaper to load all of them into OpenGL as
textures (each sprite, not the sheet entirely) or use SDL to pick pieces of the
sheet out, blit them together, and then pass the blitted surface onto OpenGL as
a texture (which means I’d have to create one every frame since the image is
constantly changing) and only then rotate it.

OpenGL is going to be much, much faster in almost all cases, unless you
can’t guarantee hardware acceleration will be available, or you have
hundreds of megabytes of sprites that are used all the time with no
discernable pattern.

Blitting is expensive, doubly so when you consider that you have access
to hardware-accelerated texture mapping as an alternative.

–ryan.

Stoned koala bears drooled eucalyptus spit in awe as Anton Mikhailov
said:

from one surface to another, which would make it roughly O(N) where N is the
number of pixels, but I dont know the constant factors and general real world

Yep, but the cost will depend on what format conversions have to be
performed. If the surfaces are the same format, it’s basically memcpy;
if it has to convert, do colour-keying or alpha, it’s gonna cost a lot
more.

Limiting factor in all cases is likely to be memory bandwidth,
particularly if one surface is on the video card, though this is a bit
of a guess on my part. Blits have good cache locality and the CPU is
more than capable of keeping up with the memory.

Reason I ask is, I am in am doing an app where several images have to be
combined together, rotated, then finally placed onto the screen. I have sprite
sheets of the items I have to splice, and will be using OpenGL to rotate the
final image. So I’m wondering if its cheaper to load all of them into OpenGL as

aha. So do it all in GL. Like Ryan says, it will be much much faster
as long as you have texturing hardware and don’t have to repeatedly
download the sprites to the video card, i.e. your sprite sheets are
relatively static.

textures (each sprite, not the sheet entirely) or use SDL to pick pieces of the

Personally I’d combine as many sprites onto a sheet as possible
(dynamically; will depend on max supported texture size of the device),
grouped by expected access pattern. That way, you reduce the number of
times you have to do a state-change, i.e. select a new texture.

constantly changing) and only then rotate it.

If you’re using GL, just rotate each sprite as you’re drawing it; no
need to double-handle them. It’s just one change to the modelview
matrix (you seem to have one single global rotation since you were
planning on blitting first then rotating the result of all the blits)
and everything will come out rotated for free.

(if people want me to stop polluting the list with GL stuff, do say so
and I’ll try to reply in private to such questions)–
William Brodie-Tyrrell

Carpe Diem - fish of the day.

<@William_Brodie-Tyrre>
http://www.brodie-tyrrell.org/

Thanks a lot for your input guys. I’ve meditated it on it a bit and decided that
putting it all together through opengl is much better. I wasnt well versed in it
and my code was already set up for SDL surfaces but its a quick enough revamp
that it will be well worth it.

Anton.