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.