Disabling double buffering

I’m working on a method of implementing multi-buffering (double and higher)
without h/w pageflipping, but I have one major performance problem: On most
targets, it seems to be impossible to disable double buffering. Rendering
is always done into a back buffer, and then blitted to the front buffer.

My problem is that I can’t render into the back buffer (I’d need at least two
of them to do that), so I render into textures, which are then blitted to the
back buffer, and then blitted again to the front buffer.

Is there a shortcut to do what SDL_UpdateRect() does, but from another back
surface, or it it time for another hack? :slight_smile:

(This is proof-of-concept code, so I’m not really worried about portability
or anythnig at this point. What I’m doing doesn’t belong on the application
side in the first place; it only happens to be the easiest way of testing the
method.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

Bigger problem right now: I need to do some hack to implement or emulate
asynchronous rendering from one thread as the same time as another thread is
managing the actual display… Looks complicated, to say the least.

Of course, I could resort to software rendering for now, I guess… Would SDL
be thread safe enough to do software pure software rendering in one thread
and h/w accelerated blitting in another, or do I still have to avoid SDL
calls altogether for the rendering thread?

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 22 February 2001 04:08, David Olofson wrote:

I’m working on a method of implementing multi-buffering (double and higher)
without h/w pageflipping, but I have one major performance problem: On most
targets, it seems to be impossible to disable double buffering. Rendering
is always done into a back buffer, and then blitted to the front buffer.

My problem is that I can’t render into the back buffer (I’d need at least
two of them to do that), so I render into textures, which are then blitted
to the back buffer, and then blitted again to the front buffer.

Is there a shortcut to do what SDL_UpdateRect() does, but from another back
surface, or it it time for another hack? :slight_smile:

(This is proof-of-concept code, so I’m not really worried about portability
or anythnig at this point. What I’m doing doesn’t belong on the application
side in the first place; it only happens to be the easiest way of testing
the method.)

Of course, I could resort to software rendering for now, I guess… Would SDL
be thread safe enough to do software pure software rendering in one thread
and h/w accelerated blitting in another, or do I still have to avoid SDL
calls altogether for the rendering thread?

It sounds like you need to try this at a lower level. I would recommend
the framebuffer console because you have more direct control over the hardware
and don’t have to worry about multi-threaded X protocol issues.

I wouldn’t try to hack it into SDL at this point. Instead I would use the
information in experiments for SDL 1.3 (or 1.3 experimental, or whatever)

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Yeah, I think that’s the easiest way to go. Oh, I can still hack an
SDL based demo, but that would be single threaded and callback based
instead.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 22 February 2001 07:23, Sam Lantinga wrote:

Of course, I could resort to software rendering for now, I
guess… Would SDL be thread safe enough to do software pure
software rendering in one thread and h/w accelerated blitting in
another, or do I still have to avoid SDL calls altogether for the
rendering thread?

It sounds like you need to try this at a lower level. I would
recommend the framebuffer console because you have more direct
control over the hardware and don’t have to worry about
multi-threaded X protocol issues.

I wouldn’t try to hack it into SDL at this point. Instead I would
use the information in experiments for SDL 1.3 (or 1.3
experimental, or whatever)