[haiku-appserver] Re: drawing thread

Hi :)

> >>Blit from front buffer to the back one so the two buffer be 
> > > identical 
> >>at this moment.
> > 
> > So, can be done, but adding the third buffer makes the whole setup 
> > 'transparant' to the system and apps, while without this a lot of 
> > app_server support is needed, and also BDirectWindow apps get into 
> > trouble (I think?)
> 
>       I have some doubts.
>       Are you talking about page flipping? Once we've done that, if I'm 
> not wrong, we loose compatibility 
> with R5 - BWindowScreen; as it writes to the location which is now 
> the backbuffer.

We have to make sure we look from the same viewpoint to this thing.
Let's see:
1. app_server / BDirectWindow /apps/whatever
2. third buffer, previously the one and only 'onscreen' buffer, now 
always offscreen (but still in graphicsmemory)
3. two buffers, page-flipping during (every) retrace.

Say, the accelerant simply does this:
-waitfor retrace;
-flip to buffer #2
-blit 'third buffer' (back-buffer you called it) to buffer #1, which is 
now invisible
-waitfor retrace;
-flip to buffer #1 (making visible _everything_ done in the 
backbuffer!!)
-blit 'third buffer' (back-buffer you called it) to buffer #2, which is 
now invisible
-repeat from first step above.

With this setup, the whole system is completely transparant to the 
current drivers, making no single modification nessesary inside the 
system or apps (if I can manage the engine correctly that is: but for a 
test I can simply force R5 to work without acceleration, and use the 
engine for the sole purpose of doing this double-buffer feature: that I 
am sure will work 100% OK.)

>       IMHO, the only solution, is to always draw into the backbuffer and 
> then blit into front buffer 
> during retrace.
Correct. By adding a third buffer this setup remains! (only the 
backbuffer is the 'third buffer' and the front buffer is alternating #1 
and #2: _but_ we now draw in the one of those two that's _currently_, 
_temporary_ offscreen giving us loads of time to do it in :-)

>       I don't see how triple buffering could solve our/(this?) problem. 
> (??)
How about now?

Rudolf.

Other related posts: