Fastest possible SDL blits

How do I get the fastest possible ordinary opaque rectangular blit in
SDL on Windows 2000 ? I turned off the SDL_SRCALPHA and
SDL_SRCCOLORKEY flags on the source surface. My source and
destination surfaces are the same depth.

Still the SDL blit times take about 400 times longer than what I can
do in DirectX. Any advice ?

Allen

Forgot to mention in my previous message below that these are blits from
a surface in system memory to a screen surface.

Allen

“Allen W. Ingling” wrote:> How do I get the fastest possible ordinary opaque rectangular blit in

SDL on Windows 2000 ? I turned off the SDL_SRCALPHA and
SDL_SRCCOLORKEY flags on the source surface. My source and
destination surfaces are the same depth.

Still the SDL blit times take about 400 times longer than what I can
do in DirectX. Any advice ?

Allen


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Sounds like you’re not getting a DMA blit. This is a serious issue on any
AGP or PCI based system, and the bus and video cards just aren’t designed
to deal with the way CPUs transfer data.

On many SDL targets, it’s not at all possible to do DMA blits from system
RAM (because the drivers don’t support it - it’s not SDL’s fault). I’m
not sure if it is at all supported by SDL, but if it is, it should work
with DirectX.

Note that there’s more to it than the depth. Are you using
SDL_DisplayFormat()? (The pixel formats must be identical! RGB->BGR
would result in a software blit with on-the-fly conversion.)

And as to the “400 times faster” - I don’t think there’s any way to get
that kind of difference in actual blitting speed. (Well, there might
be, if you’re comparing an opaque h/w blit to a software alpha blit from
the wrong pixel format, perhaps… :slight_smile:

What you’re seeing with DirectX is the time it takes to enqueue the blit
command and possibly start the blit, but not the time it takes to
complete the blit.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 19 October 2001 05:41, Allen W. Ingling wrote:

Forgot to mention in my previous message below that these are blits
from a surface in system memory to a screen surface.

David Olofson wrote:

Note that there’s more to it than the depth. Are you using
SDL_DisplayFormat()? (The pixel formats must be identical! RGB->BGR
would result in a software blit with on-the-fly conversion.)

Duh. No I wasn’t using SDL_DisplayFormat(). Much better now, thanks for the
helpful reply.

What you’re seeing with DirectX is the time it takes to enqueue the blit
command and possibly start the blit, but not the time it takes to
complete the blit.

So if blits are asynchronous, how do I detect when they are have completed ?
On SDL 1.2 under windows 2K, does SDL_LockSurface when called on the
destination surface return only after the blit is completed ? (The timing
seems to be about what I would expect if this were true, and if a blit is
going on then it does make some sense that I could not lock the surface.) If
that is the case, is that an artifact of the Windows implementation of SDL or
is this behavior by design, meaing should SDL demonstrate the same behavior
on all platforms ?

Finally, assuming using locks work to detect end of blits, then on platforms
for which SDL_MUSTLOCK(surface) evaluates to 0, any ideas on how to measure
blit times ?

Allen

[…]

So if blits are asynchronous, how do I detect when they are have
completed ?

SDL will block when you try to lock the screen surface, or any hardware
surface involved in the blit.

Either way, the idea is that SDL_Flip() syncs with the retrace to achieve
smooth animation. If it doesn’t (which is the case on many targets),
you’ll still stay more or less in sync with rendering, as no target has
infinite command buffer deepth.

On SDL 1.2 under windows 2K, does SDL_LockSurface when
called on the destination surface return only after the blit is
completed ? (The timing seems to be about what I would expect if this
were true, and if a blit is going on then it does make some sense that
I could not lock the surface.) If that is the case, is that an
artifact of the Windows implementation of SDL or is this behavior by
design, meaing should SDL demonstrate the same behavior on all
platforms ?

That’s how it works on all targets with hardware blitting. (Also
applies to the software async blit for multiple CPU machines, activated
with the SDL_ASYNCBLIT flag.)

It’s not an artifact, as it has to work that way on any platform.
DirectX works exactly the same way - you can’t lock a surface while a
blit is in progress.

As to the “exception” of software surfaces, it actually isn’t an
exception. It’s just that you don’t need locking if you’re only allowed
to use one thread.

Finally, assuming using locks work to detect end of blits, then on
platforms for which SDL_MUSTLOCK(surface) evaluates to 0, any ideas on
how to measure blit times ?

If SDL_MUSTLOCK(surface) == 0, you’re using software blitting, and/or the
blit call will return when the blit has completed.

I don’t know if this is a guaranteed safe way to find out if a blit is
entirely completed though.

For example, using the 2D-on-OpenGL layer I hacked last weekend, SDL
surfaces and locking has little to do with the actual rendering. When a
blit call returns - and even when a subsequent lock call returns - it
means only that the surface is converted and downloaded, and that the
"blit" is in the OpenGL command queue, or in the 3D card command buffer.
The actual blit won’t be performed until you eventually call SDL_Flip()
or SDL_UpdateRects - and you can’t even be sure that all blits are
performed in the order you commit them to the API.

It’s entirely possible that some platforms have 2D APIs that work in
similar ways, and it might even be transparent to SDL.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 19 October 2001 23:22, Allen W. Ingling wrote: