FreeLists / haiku-appserver / [haiku-appserver] Re: drawing thread

[Adi Oanca <adioanca@xxxxxxxxxxxxxx>]

Rudolf wrote:
> 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)

        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.

        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.

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

        I'm not entirely sure, but app_server does not know when to blit when a 
BDirectWindow is at use.

        Dunno, seems complicated when it could be done easy...


bye,
Adi.