[haiku-appserver] Re: drawing thread

Hello!

Sorry for being nosy, but I just love to follow Haiku's development,
and I believe I have a llittle chance to help here. Not with code, but
with some clarification, as I'm seeing some misconceptions in this
discussion:

(superficial) Working around flickering and tearing:
http://www.azillionmonkeys.com/qed/flicker.html

(a little more in-depth) A tripple-buffering implementation:
http://www.vrjuggler.org/vrjuggler/2.0-alpha4/programmer.guide/programmer.guide/ch08s04.html

(pro stuff ;D) A VERY comprehensive guide on the vsync, tearing and
buffering issues:
http://www.teamradeon.com/articles/guides/vsync/vsync_guide.asp

I hope this helps ;)


Cheers,
A.


-- 
"A year spent in artificial intelligence is enough to make one believe in God"
Alan J. Perlis


> >       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.
> 
>

Other related posts: