[haiku-appserver] Re: drawing thread
- From: André Braga <meianoite@xxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Mon, 8 Nov 2004 15:07:52 -0200
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:
