[SDL] Faster way to do an SDL_BlitSurface

Manuel García Cabrera manugarciac5 at yahoo.com.ar
Fri May 4 09:53:41 PDT 2007


Brian escribió:
> Where did you hear memcpy would be faster?
> 
> SDL_BlitSurface is already highly optimised, taking advantage of
> various special instructions available on different CPUs. If the SDL
> developers found that memcpy could blit faster on a particular
> platform, then that's what they would use.
> 
> As for why you are getting a corrupted display, are both surfaces
> software surfaces? If not you'll need to lock hardware ones. Do they
> both share the same BitsPerPixel and colour formats? You may find that
> converting all surfaces to software can improve performance anyway,
> depending on the types of surfaces (alpha blending in particular, and
> any pixel manipulation are horribly slow on hardware surfaces).
> Another potential time saver would be do blit the large image (which
> Im assuming is a background) once, and only re-blit small portions of
> it when a sprite moves across the screen. For a static background this
> will really help.
> 
> Finally however, I will point you to Bob Pendleton's excellent articles on SDL:
> http://www.oreillynet.com/articles/author/1205
> 
> There's some very good information about SDL and blitting in these,
> they are well worth the read.
> 
> Cheers,
>       Brian.
> 
> On 5/4/07, Manuel García Cabrera <manugarciac5 at yahoo.com.ar> wrote:
>> I heard that with memcpy it should be faster, and it seems to be, but
>> the result is not good.
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
> 


Mmmm, I found out that the BlitSurface isn't necesarily the one eating
my time... I'll explain a little bit what I'm displaying: I have an
aplication that captures the screen, XORs with the previous screen
capture and compresses it before writing on a file. It does that as fast
as it can. Ok, when on the Player side, I open the file, read the data
from the file, uncompress it, XOR it and show it.

Ok, now I know that BlitSurface isn't necesarily eating my time. The
pics I send through the file are 24bit bitmaps. If I do SDL_Init with my
current color depth (that would be 32 bits) the one eating the time is
indeed SDL_BlitSurface. However, if I do the SDL_Init with 24bits as
color depth, the BlitSurface is practically auotomatic (the memcpy works
here too), but the SDL_UpdateRect eats the time now... Even more that
the BlitSurface in the previous case...

Any ideas of what I could to do speed this up?


More information about the SDL mailing list