[SDL] Flickering DX.

[David Olofson]

On Monday 05 November 2007, Miguel Pragier wrote:
> David Olofson <david <at> olofson.net> writes:
> 
> > 
> > On Monday 05 November 2007, Miguel Pragier wrote:
> > > When I use DirectX, my screen is flickering.
> > 
> > How? Directly or via SDL? If the latter, are you using SDL 1.2 
> > (stable) or 1.3 (development)? (These have rather different video 
> > subsystems.)
> 
> Thru SDL 1.2.
> 
> > 
> > I don't think you would be able to set up a display at all if it 
> > wasn't.
> 
> Yes, now I know ;-)
> 
> 
> Every modern videoboard supports DoubleBuffering?

Yes - and triple buffering, and other configurations as well. It's 
mostly limited by drivers and/or APIs.


> Or is this technique obsolete?

It's the only practical way of animating graphics without tearing or 
flickering, so I don't think it's going away any time soon. :-)

However, there are many different ways of implementing double 
buffering! There are basically two scenarios that you have to be 
aware of when using SDL:

1) The "real", efficient method, which is what most serious
   drivers use when possible, is to have two separate buffers
   that are directly available to the video card's RAMDAC.
   This way, a "flip" is only a matter of changing a pointer -
   no copying of graphics data needed.
      Flips *may* be synchronized with the display refresh to
   avoid pumping out frames that no one will see, and to avoid
   tearing. No guarantee though, as some platforms and drivers
   don't support it, and many drivers come with it disabled
   in the driver settings by default.

2) Another rather common method, used in most cases on Linux
   (OpenGL and X11 alike), SDL in windowed mode on most
   platforms etc, is to have only one actual display buffer,
   and perform flipping by physically copying the "drawing page"
   into the display buffer when "flipping".

The second approach is slower and makes retrace sync very hard to do 
properly (which causes tearing) - but it has the advantage that the 
application is always rendering into the very same buffer, which 
makes smart updates simpler to get right.

You can force SDL to use the second method by requesting a software 
display surface, but then you definitely lose the retrace sync, and 
have to rely on manual "throttling" to avoid a constant 100% CPU 
load. Well, you should actually have that throttling logic either 
way, as you don't know if you'll get retrace sync even if you get a 
hardware display surface.

Now, if you redraw the whole screen every frame (like a full screen 
scrolling game would do anyway), the difference between the modes is 
irrelevant an far as flickering is concerned, as you never depend on 
old data in the buffers. Obviously though, you don't want to do this 
in applications with mostly still screens, as it's just be a waste of 
CPU or GPU cycles and/or substantially raises the minimum system 
requirements.


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'