Hello
I have been benchmarking the SDL_Flip() routine. On my Linux box it
takes 12 msec (plus or minus 0.4 msec) to execute and return (this is
very consistent). The flip is called in response to user input and as
such could be called at any stage of the refresh cycle. Therefore this
consistent latency must not be due to waiting for the vertical retrace.
Can I presume that when the flip is called, the routine sets up the flip
rapidly (by changing the pointer to the buffer) but the majority of the
12 msec delay is due to waiting for a new rendering buffer from the
driver. If so, is there any way of determining what percentage of this
duration is setting up the flip and how much is in waiting for the
buffer?
Cheers
Sean
Please correct me if I am wrong, but SDL_Flip() is intended
to be used together with hardware surface, which is not
supported under X11. In this case, SDL_Flip() is equal to
SDL_UpdateRect(). So your 12 ms could be all block transfer
time from main memory to video memory.
Regards,
.paul.On Tue, Jun 17, 2003 at 05:25:13PM +0930, Sean Fitzgibbon wrote:
Hello
I have been benchmarking the SDL_Flip() routine. On my Linux box it
takes 12 msec (plus or minus 0.4 msec) to execute and return (this is
very consistent). The flip is called in response to user input and as
such could be called at any stage of the refresh cycle. Therefore this
consistent latency must not be due to waiting for the vertical retrace.
Can I presume that when the flip is called, the routine sets up the flip
rapidly (by changing the pointer to the buffer) but the majority of the
12 msec delay is due to waiting for a new rendering buffer from the
driver. If so, is there any way of determining what percentage of this
duration is setting up the flip and how much is in waiting for the
buffer?
Cheers
Sean
No it was ment to be used with anything you wish. Software or hardware
buffers, double buffering or not. It works with them all.On 17-Jun-2003, paul at theV.net wrote:
Please correct me if I am wrong, but SDL_Flip() is intended
to be used together with hardware surface, which is not
supported under X11. In this case, SDL_Flip() is equal to
SDL_UpdateRect(). So your 12 ms could be all block transfer
time from main memory to video memory.
Regards,
.paul.
On Tue, Jun 17, 2003 at 05:25:13PM +0930, Sean Fitzgibbon wrote:
Hello
I have been benchmarking the SDL_Flip() routine. On my Linux box it
takes 12 msec (plus or minus 0.4 msec) to execute and return (this is
very consistent). The flip is called in response to user input and as
such could be called at any stage of the refresh cycle. Therefore this
consistent latency must not be due to waiting for the vertical retrace.
Can I presume that when the flip is called, the routine sets up the flip
rapidly (by changing the pointer to the buffer) but the majority of the
12 msec delay is due to waiting for a new rendering buffer from the
driver. If so, is there any way of determining what percentage of this
duration is setting up the flip and how much is in waiting for the
buffer?
Cheers
Sean
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
Patrick “Diablo-D3” McFarland || unknown at panax.com
“Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music.” – Kristian Wilson, Nintendo, Inc, 1989
Hello
I have been benchmarking the SDL_Flip() routine. On my Linux box it
takes 12 msec (plus or minus 0.4 msec) to execute and return (this is
very consistent). The flip is called in response to user input and as
such could be called at any stage of the refresh cycle. Therefore
this consistent latency must not be due to waiting for the vertical
retrace. Can I presume that when the flip is called, the routine sets
up the flip rapidly (by changing the pointer to the buffer) but the
majority of the 12 msec delay is due to waiting for a new rendering
buffer from the driver. If so, is there any way of determining what
percentage of this duration is setting up the flip and how much is in
waiting for the buffer?
We really need more information to answer the question. If you are using
hardware buffers, then my guess is that your screen refresh rate is just
about 84 frames/second and what you are seeing is exactly what you would
expect to see.
My guess is that you are using hardware buffers and you are not ever
locking the buffers. So, the first time you call SDL_Flip() it is
scheduling a buffer swap and returning immediately. Then you go off and
do some work. When that work is done you call SDL_Flip() again. At that
point SDL_Flip() has to lock the buffers, but is blocked for 12
milliseconds while the hardware is waiting for the vertical retrace to
do the actual buffer swap (pointer change). As soon as the pending
buffer swap completes, SDL_Flip() schedules another buffer swap and
returns. After it returns, you do some work and call SDL_Flip() again,
which again has to wait for the last buffer swap to complete before it
can schedule the new buffer swap, and so it waits another 12
milliseconds. And so on…
If you were locking the buffer somewhere you would see the 12
millisecond wait around the call to lock the buffer or when you call
SDL_Flip(). But not necessarily always at the same place.
In other words, this is normal behavior and just shows that your
processing is going very fast.
Bob PendletonOn Tue, 2003-06-17 at 02:55, Sean Fitzgibbon wrote:
Cheers
Sean
–
±----------------------------------+
- Bob Pendleton: independent writer +
- and programmer. +
- email: Bob at Pendleton.com +
±----------------------------------+