SDL_Flip manpage change proposal

SDL Development
1

Hello,

I noticed that when I run testsprite program on my computer (with ATI
Radeon 7500 QW driven by XFree 4.2.0 @1600x1200 on Linux 2.4.18) with
SDL_VIDEODRIVER set to dga and with parameters -flip -hw, I get this
output:

Screen is at 16 bits per pixel
Screen is in video memory
Screen has double-buffering enabled
Sprite is in video memory
Sprite blit uses hardware acceleration
600.89 frames per second

and the screen flickers as hell (no wonder if it’s running @600 fps).
So far so good, but:

  • man SDL_Flip says “The hardware will wait for vertical retrace,
    and then swap video buffers …” etc. Obviously this is not true on
    my system - if the hardware really waited for VSYNC the program could
    hardly display 600 fps with such a flicker. So I would suggest
    changing that sentence to something that actually warns the reader
    that on some systems the waiting for VSYNC will not work.

  • once this is done, it could be nice if the manpage could give the
    reader some pointer as to how he can find out whether waiting for
    VSYNC will work on his own machine.

  • could someone explain to me why waiting for VSYNC doesn’t work on my
    machine? I mean, XDGAQueryModes() returns XDGAFlipRetrace among flags
    for 1600x1200 at 16bpp mode (or any other mode, for that matter) so it
    seems to me that DGA can wait for retrace, right? Is SDL the culprit
    here? Can SDL use the DGA XDGAFlipRetrace capability?

Thanks for your answers.

latimerius
2
  • man SDL_Flip says “The hardware will wait for vertical retrace,
    and then swap video buffers …” etc. Obviously this is not true on
    my system - if the hardware really waited for VSYNC the program could
    hardly display 600 fps with such a flicker. So I would suggest
    changing that sentence to something that actually warns the reader
    that on some systems the waiting for VSYNC will not work.
  • once this is done, it could be nice if the manpage could give the
    reader some pointer as to how he can find out whether waiting for
    VSYNC will work on his own machine.

Unfortunately, it may not be possible for SDL to know whether the underlying
drivers are actually waiting for VSYNC. The general rule of thumb is that
if you are running fullscreen and ask for SDL_DOUBLEBUF and actually get it,
then you’re probably sync’d with vertical retrace.

  • could someone explain to me why waiting for VSYNC doesn’t work on my
    machine? I mean, XDGAQueryModes() returns XDGAFlipRetrace among flags
    for 1600x1200 at 16bpp mode (or any other mode, for that matter) so it
    seems to me that DGA can wait for retrace, right? Is SDL the culprit
    here? Can SDL use the DGA XDGAFlipRetrace capability?

It can and does, and it works like a champ on the Matrox and NVidia drivers.
I suspect that it’s a bug in the ATI drivers. Have you tried upgrading your
X server to the latest version?

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

3
  • man SDL_Flip says “The hardware will wait for vertical retrace,
    and then swap video buffers …” etc. Obviously this is not true on
    my system - if the hardware really waited for VSYNC the program could
    hardly display 600 fps with such a flicker. So I would suggest
    changing that sentence to something that actually warns the reader
    that on some systems the waiting for VSYNC will not work.
  • once this is done, it could be nice if the manpage could give the
    reader some pointer as to how he can find out whether waiting for
    VSYNC will work on his own machine.

Unfortunately, it may not be possible for SDL to know whether the underlying
drivers are actually waiting for VSYNC. The general rule of thumb is that
if you are running fullscreen and ask for SDL_DOUBLEBUF and actually get it,
then you’re probably sync’d with vertical retrace.

But on XFree86 specifically, it should be possible to tell by checking
XDGAFlipRetrace flag, right? Unless there’s a bug in driver, as you
stated.

  • could someone explain to me why waiting for VSYNC doesn’t work on my
    machine? I mean, XDGAQueryModes() returns XDGAFlipRetrace among flags
    for 1600x1200 at 16bpp mode (or any other mode, for that matter) so it
    seems to me that DGA can wait for retrace, right? Is SDL the culprit
    here? Can SDL use the DGA XDGAFlipRetrace capability?

It can and does, and it works like a champ on the Matrox and NVidia drivers.
I suspect that it’s a bug in the ATI drivers. Have you tried upgrading your
X server to the latest version?

It’s an xserver binary I downloaded directly from xfree86.org
distribution site (because I’m on Debian and they haven’t included 4.2.0
in their distrib yet) in the beginning of July. I can’t mess with the
machine I did my tests on too much but I expect getting access to
another equivalent hardware in a couple of days so I’ll check a newer
xserver later and let you know how it went.

Thanks,

latimeriusOn Fri, Oct 04, 2002 at 09:08:07PM -0700, Sam Lantinga wrote: