
|
[haiku-appserver]
||
[Date Prev]
[11-2004 Date Index]
[Date Next]
||
[Thread Prev]
[11-2004 Thread Index]
[Thread Next]
[haiku-appserver] Re: drawing thread
- From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Mon, 01 Nov 2004 13:11:51 +0100 CET
Hi,
ADI wrote:
> > The difference between the setup as below, and the triple setup, is
> > that in the setup below the blit from back to front buffer has to
> > be
> > done and completed _during_ retrace (doable I would guess);
> > While with the triple version you only need to flip during retrace.
> > Actual drawing from back to 'front' buffer may here be much slower.
>
> True. But then again, in the triple buffering schema, don't you
> need to draw everything in every
> flippable buffer? Isn't it twice slower?
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)
Maybe it depends on implementation details like 'only updating on
actual changes made in backbuffer' (or not).
> What about apps that are directly using the frame buffer? Won't
> they always draw into the first
> flippable buffer?
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.
Rudolf.
|

|