SDL_SetVideoMode ignores flags & SDL_Flip is slow - sdl

Question

I'm initializing with
SDL_Init(SDL_INIT_VIDEO);
screen = SDL_SetVideoMode(800, 600, 32, SDL_SWSURFACE|SDL_DOUBLEBUF);
and then calling, in a loop, between calls to sleep, just
SDL_LockSurface(screen);
// Will eventually twiddle pixels here...but not yet
SDL_UnlockSurface(screen);
SDL_Flip(screen);
And that call to flip takes a varying amount of time, but around 10ms, which is a lot for nothing.
So that makes me wonder if I'm causing, say, a copy from video memory to system memory or something, and I should create the surface differently. BUT, additionally, screen->flags is always equal to SDL_ASYNCBLIT and no other bits are set, regardless of the flags I pass to SDL_SetVideoMode. So I can't make any other kind of surface anyway.
Should I be creating another offscreen surface, rendering to that, and then blitting it to the screen? What am I doing wrong?
EDIT: Removing the SDL_Lock and SDL_Unlock pair does nothing to speed things up. The SDL_Flip is just slow.

Answer 1

For the sake of the two or three people that may, someday, see this question, I think the reason the SDL_Flip takes so long is that it waits for vsync, so a busy loop calling SDL_Flip will necessarily be limited by the vsync rate.
If that's correct, the fact that SDL_Flip takes so long is not an actual issue, since if I were doing work to render things, then there'd be less time to wait for the vsync.

Answer 2

I use Win7, Codeblocks/MingW, SDL 1.2.14. Grumdrig said:
For the sake of the two or three people that may, someday, see this
question, I think the reason the SDL_Flip takes so long is that it
waits for vsync, so a busy loop calling SDL_Flip will necessarily be
limited by the vsync rate.
If that's correct, the fact that SDL_Flip takes so long is not an
actual issue, since if I were doing work to render things, then
there'd be less time to wait for the vsync.
Nah, something is wrong. My programs performed fine until relatively recently, and I spent awhile myself today looking for the cause of my own bottleneck, which turned out to be SDL_Flip() like yours, which led me to your question through a google search. Interestingly enough, on my older WinXP single core the performance is better, so my guess is that the problem is caused by the friendly Win7 auto-updates. Perhaps Microsoft is unintentionally de-optimizing the GDI!
In any case, SDL_Flip shouldn't take so long to resolve itself, and in case anyone is wondering, I put a Uint32 SDL_Getticks() timer above SDL_Flip() and outputted the length below if it was over 5 ms. The result was numbers like 27, 59 and 88 milliseconds from time to time, which is not good. And of course, the problem is the same whether I use SWSURFACE or HWSURFACE as the flag to SetVideoMode.
Before I leave a comment on the SDL website I may try rebuilding with SDL 1.2.15, though that might require a rebuild of SpriG, so I'm not in a rush. But in general, I stand by what I said: chances are, it's a Win7 thing, if that's your operating system.
Addendum 5:17 PM EST: I just compiled and ran a smaller, unrelated project that uses SDL 1.2.15 and the problem was the same: normal smooth movement followed by occasional jerks. Testing for only when SDL_Flip() took more than 5 milliseconds, the output included values ranging from 30 to over 60 milliseconds, which would happen about once every second or two.
Addendum 5-8-12: On 5-4-12 there was a big thunderstorm and I had to turn off and unplug the computer, with the result that the next day SDL_Flip() always took under 5ms, so the problem is solved now.