FreeLists / haiku-appserver / [haiku-appserver] Re: drawing thread

["Rudolf" <drivers.be-hold@xxxxxxxxxxxx>]

Hi Adi,

> > I guess you have to make sure the shown buffer is upto date in both 
> > setups. So it doesn't matter then if you update the same buffer 
> > over 
> > and over again, or if you do both alternatively (it's needed never 
> > at 
> > the same time)
> 
>       I'd dare to say you're wrong.
>       If you don't update/blit with the same area/rectangle after the 
> page flip, surely you won't be 
> having the same image next time when you flip.
Indeed. So if flipping would be done on every retrace you are right: 
the same image must be blitted to both the two buffers.

>       Again, I don't see the usefulness in having three buffers. Either 
> way, you have to blit from the 
> back buffer to flippsurface #2, and if the flip occurs at this time, 
> it is exactly the situation 
> with simple double buffering - page flipping is not useful anymore.
Yes, correct. However I was thinking to blit somewhere during mid-
screen on the currently offscreen buffer. So synced somehow to retrace 
indeed.

But, lets' forget about the triple buffer thing. As I already agreed 
with you just two buffers, and blitting during retrace is fine: as long 
as it's a hardware accelerated blit: otherwise it will be too slow. 
(and in _this_ case only, the triple buffer thing would be needed)

> > No: back buffer. As far as they are concerned this _is_ the 
> > framebuffer 
> > I'd say. It's up to 'another process' to make that buffer shown 
> > after 
> > the next upcoming retrace.
>       I'm not entirely sure, but app_server does not know when to blit 
> when a BDirectWindow is at use.
That's true. So it would be possible that the blit works on a partly 
updated BDirectWindow window, which would show a partly updated screen 
then: so an 'artifact'. However, on the next screen drawing it will be 
blitted again, and then it will be completed. (at least no change is 
executed during mid-screen on-screen, which should at least minimize 
the distortion for this particular thing)

>       Dunno, seems complicated when it could be done easy...
Yep, every advantage also has it's downsides I guess. Anyway: don't set 
this up (or whatever other non-R5 feature that sounds complicated) for 
R1 anyway ;-)

I was merely suggesting options that exist in theory, and surely you 
can see both downsides _and_ upsides of both double- and triple 
buffering.

Hey: shall we drop the subject now?
I've mumbled everything I had to say by now ;-)

BTW: Keep up the good job! I just also saw that Axel has the echo of 
the shell stuff working now, and that Haiku works on real hardware. 
Nice to see improvements happening 8-) 

(congrats Axel)

Rudolf.