[haiku-appserver] Re: drawing thread

  • From: André Braga <meianoite@xxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 8 Nov 2004 15:07:52 -0200


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

(superficial) Working around flickering and tearing:

(a little more in-depth) A tripple-buffering implementation:

(pro stuff ;D) A VERY comprehensive guide on the vsync, tearing and
buffering issues:

I hope this helps ;)


"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: