[SDL] Double-buffering *and* dirty rectangle lists?

[David Olofson]

On 26/08/2002 14:24:12 , Loren Osborn <linux_dr at yahoo.com> wrote:
>On Mon, 2002-08-26 at 05:49, David Olofson wrote:
[...]
>> Yeah, but that's only a problem with effects that take data from the
>> frame buffer as input. (Recursive blending and blurring effects and such.)
>> Such effects implemented directly towards VRAM (ie VRAM reading) would be
>> painfully slow anyway, so I'm not even considering them.
>> 
>> As long as you stick to plain opaque blits to the video buffer, things
>> should work as expected. The only thing that happens if you assume
>> "real" double buffering but get a single shadow back surface, is that
>> you'll waste time updating everything twice.
>> 
>> 
>
>
>I disagree... If you have an object moving from position A to B to C to
>D in consecutive frames: When the application goes to draw the object at
>location C, it should erase the object from location A, but *NOT* from
>location B if it assumes real double buffering... Likewise it you it is
>dealing with TRIPPLE buffering instead, when it is drawing the object at
>location D, it should erase the object at location A, but *NOT* at B or
>C. 

Right, but it doesn't matter if you're doing *more* work than required. (Except that you're wasting time, obviously.)

The whole point with one set of dirty rects per buffer is to reliably
ensure that everything that needs updating in each buffer is updated.
If there in fact is only one real buffer, the extra "history" dirty
rects will just cause areas that are already up to date to be updated
again, for no visible effect.


> Basically to do this with utmost efficiency, you need to know
>EXACTLY how many buffers there are,

Of course - but I'm not talking about efficiency, but rather about
whether or not you will get correct results despite the fact that
many drivers and targets either refuse to tell you what's going on,
or lie about it.


> (and exactly what order they are
>being given to you)...

Yes, but as most targets don't even support anything but a simple
circular chain (even if other schemes could be of use in some cases
:-/ ), this doesn't seem to be a real problem.


>*SAM PLEASE READ THE FOLLOWING, I would like your feedback on such an
>API change:*
>
>Perhaps that is the solution.  SDL could add a function to query the
>number of buffers, assign each buffer an index number, and add a
>function to querey the index number of the current buffer.

This is not possible to implement on any target I know of. (Well,
unless programming directly to the metal like in the DOS days counts,
of course. However, SDL doesn't run on DOS, AFAIK.)


> That way you
>could develop a general solution that supports both emulation and
>tripple buffering.

I think SDL can generally tell (or rather, dictate) whether there
will be double buffering or emulation. Triple buffering is not
supported, so the only time you could possibly get that would be
when the driver or system does is behind your back. (Can't think
of any drivers other than OpenGL and Direct3D that would do such
a thing.)


[...]
> From experience with DirectX, I
>know the system (Windows at least) will clear the frame behind your
>back. 

That's interesting... Why would a driver waste blitting time clearing
buffers automatically.? (If DX does that all the time, that certainly
explains why plain "frame pumping" is much slower than expected on
some cards...)


> SDL should probably detect and report this also. (We detected it
>by keeping a non-zero pixel in one known corner, and reporting when it
>got zeroed).

*heh* Well, there's no end to what application programmers have to do
to work around the traps set up by the guys in Redmond... ;-)


//David


.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se
|---------------------------------------
| Address:
| REOLOGICA Instruments AB
| Scheelevägen 30
| 223 63 LUND
| Sweden
|---------------------------------------
| Phone: 046-12 77 60
| Fax: 046-12 50 57
| Mobil: 
| E-mail: david.olofson at reologica.se
| WWW: http://www.reologica.se
| 
`-----> We Make Rheology Real