Hi all!
does anyone know about strange timeout in hardware screen surface with
doublebuffering. Next pseudo-code:
…
SDL_Init(SDL_INIT_VIDEO)
…
screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE|SDL_DOUBLEBUF|
SDL_ANYFORMAT)
…
tmp = SDL_CreateRGBSurface(with screen parameters)
buffer = SDL_DisplayFormat(tmp)
…
test “screen” and “buffer” on flags SDL_HWSURFACE
…
for same times
time1[] = SDL_GetTicks()
SDL_BlitSurface(buffer, NULL, screen, NULL)
test “buffer” on hardware blit flag
time2[] = SDL_GetTicks()
SDL_BlitSurface(buffer, NULL, screen, NULL)
test “buffer” on hardware blit flag
time3[] = SDL_GetTicks()
SDL_Flip(screen)
time4[] = SDL_GetTicks()
end for
…
print: time1[n]-time1[n-1] (time2-time1) (time3-time2) (time4-time3)
“time between frames” “time blit operation” “time blit operation” “time flip
operation”
…
Typical times (60 HZ vertical refresh) with small variations of value range
16 0 0 0
It’s good and right, becouse first operation with video memory after Flip
waits video refresh.
BUT, if in other console run CPU-like task (burn or videoplayer) then
typical time is the same like before, but I have the strangeness like this:
16 0 0 0
116 0 0 0 <- !!! per 5-6 frame
Why? In fact hardware must makes blit.
What is it? How I can avoid it?
THX
PS. Tested on SDL 1.2.7 for dga, fbcon, directfb drivers;
kernel 2.4.26, 2.6.8.1;
K6-2-533, PIII-1000, AGP Video Matrox G450, Voodoo3
Hi,
I’d say the extra time is spent in another task. As you most probably
know, the CPU time must be shared among several processes. Now if you’re
doing another CPU-intensive job (as you mentioned,) when your process
blocks (waiting for video refresh) the OS gives CPU time to the other task.
The solution would be to rely on the user not to run two CPU-bound
operations together (which is almost always futile!) or to raise the
priority (in Windows for example) of your process. I don’t think that
SDL supports this.
-yzt
misha chechik wrote:> Hi all!
does anyone know about strange timeout in hardware screen surface with
doublebuffering. Next pseudo-code:
…
SDL_Init(SDL_INIT_VIDEO)
…
screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE|SDL_DOUBLEBUF|
SDL_ANYFORMAT)
…
tmp = SDL_CreateRGBSurface(with screen parameters)
buffer = SDL_DisplayFormat(tmp)
…
test “screen” and “buffer” on flags SDL_HWSURFACE
…
for same times
time1[] = SDL_GetTicks()
SDL_BlitSurface(buffer, NULL, screen, NULL)
test “buffer” on hardware blit flag
time2[] = SDL_GetTicks()
SDL_BlitSurface(buffer, NULL, screen, NULL)
test “buffer” on hardware blit flag
time3[] = SDL_GetTicks()
SDL_Flip(screen)
time4[] = SDL_GetTicks()
end for
…
print: time1[n]-time1[n-1] (time2-time1) (time3-time2) (time4-time3)
“time between frames” “time blit operation” “time blit operation” “time flip
operation”
…
Typical times (60 HZ vertical refresh) with small variations of value range
16 0 0 0
It’s good and right, becouse first operation with video memory after Flip
waits video refresh.
BUT, if in other console run CPU-like task (burn or videoplayer) then
typical time is the same like before, but I have the strangeness like this:
16 0 0 0
116 0 0 0 <- !!! per 5-6 frame
Why? In fact hardware must makes blit.
What is it? How I can avoid it?
THX
PS. Tested on SDL 1.2.7 for dga, fbcon, directfb drivers;
kernel 2.4.26, 2.6.8.1;
K6-2-533, PIII-1000, AGP Video Matrox G450, Voodoo3
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl