SDL is missing video signal synchronisasiton

SDL Development
1

What I thing is really missing from SDL is support for synchronising with the vertical retrace. For example equivalents of DirectDraw functions (in order of importance:) WaitForVerticalBlank, GetVerticalBlankStatus, GetScanLine, GetMonitorFrequency.

Rationale:

  1. Not all HW supports doublebuffer+hardware flipping.
  2. SDL_Flip only works for doublebuffering, but not for n-buffering where n=1 or n>2.
  3. I have other complaints about the SDL flipping API.

Other complaints about the SDL flipping API:

  1. No polling functiion to find out whether a flip has been completed -> must use a separate thread, even when hardware supports polling.
  2. No support for n-buffering, n>2.

Other ideas:

As for n-buffering, is it necessary for the backbuffer surface(s) to be special? Why not just be able to flip to any HW surface (of appropriate size/format)?

Perhaps we would be able to scroll just by adjusting the beginning of the video buffer within a surface?____________________________________________________________
http://www.bezpecnyinternet.cz
http://ad.seznam.cz/clickthru?spotId=94734

2

What I thing is really missing from SDL is support for synchronising with
the vertical retrace. For example equivalents of DirectDraw functions (in
order of importance:) WaitForVerticalBlank, GetVerticalBlankStatus,
GetScanLine, GetMonitorFrequency.

Well, I’m quite certain that it supports the notion of the VSync, since I
believe that’s the reson for the “Asyncblit” flag for your video surface.

As to the rest of your complaints, I’m sure someone can form a more cogent
response to them. However, one would keep in mind the cross-platform
functionality of SDL (heck, I’m using it on my handheld!) and realize it
functions for the lowest-common-denominator.

3

< > What I thing is really missing from SDL is support for synchronising with
< > the vertical retrace. For example equivalents of DirectDraw functions (in
< > order of importance:) WaitForVerticalBlank, GetVerticalBlankStatus,
< > GetScanLine, GetMonitorFrequency.
< >
< Well, I’m quite certain that it supports the notion of the VSync, since I
< believe that’s the reson for the “Asyncblit” flag for your video surface.

IMHO the SDL_ASYNCBLIT means that asynchronous blitting is possible (from the surface? to the surface?) i.e. the blitting takes place in background, while application execution continues immediately. (BTW this feature is not implemented on the DirectX target, even though it could)

This seems to be something rather different from vertical retrace synchronisation.

< However, one would keep in mind the cross-platform
< functionality of SDL (heck, I’m using it on my handheld!) and realize it
< functions for the lowest-common-denominator.

I disagree.

  1. Wheter this feature is or isn’t supported (e.g. makes no sense) on a specific device can be determined by a capability flag. (or a return value). There is absolutely no reason to condemn graphics on PCs to flicker just because your handheld video driver won’t tell you whether you’re in a retrace or not and you don’t want to bother checking a capability flag.

  2. Not only CRT monitors, but also LCDs (in notebooks and the ones connected to PCs) have vertical retrace – they rely on the same kind of videosignal (even those with digital input – only the signal uses pulse code modulation!)

Thus these LCDs behave very much like and ordinary CRT.

I beleive most displays use some serial (possibly not sequential) display update, since they have serial connection to display memory.

Has anyone actually seen a graphical display with direct update? (i.e. changes to video memory affect the display immediately and in the same order?)____________________________________________________________
http://www.bezpecnyinternet.cz
http://ad.seznam.cz/clickthru?spotId=94734

4

However, one would keep in mind the cross-platform
functionality of SDL (heck, I’m using it on my handheld!) and realize it
functions for the lowest-common-denominator.
<<<

would you suggest dropping mouse, keyboard or joystick functionality
because some platforms dont have them?.. So why limit everyone?

5

This is one of those subjects that comes up quit frequently on this
list. The thing is that SDL does wait for video sync on platforms that
support it. Because it can not be implemented on every platform and
configuration the buffer flipping API for SDL was designed so that you
get the benefits of video synchronization on platforms that support it
(and here is the genius part) without having to worry about it. The
API allows the developers of SDL to support triple buffering (and
N-buffering if it is useful) and gives you the benefit of those features
without making you worry about specifically waiting for vsync.

By hiding the details of video synchronization behind the API SDL allows
the use of the best way to get smooth animation on each platform
including using video synchronization and N-buffering where appropriate
while allowing the SDL API to be implemented on the most primitive video
displays.

There is a lot of detail on this topic in the article at
http://www.linuxdevcenter.com/pub/a/linux/2003/08/07/sdl_anim.html The
parts that cover this subject are on the second page. In the article I
do give some tricks for detecting the type of flipping being done by a
particular SDL driver.

		Bob Pendleton>

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

–
±-------------------------------------+