[haiku-appserver] Re: drawing thread

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sat, 23 Oct 2004 00:28:09 +0300


        What's =3F? What about =5F? :-)) No, really.

Rudolf wrote:
> Hi,
>>Axel D=F6rfler wrote:
>>>When you have a setup like this, all threads could even 
>>>access the main memory, since they will all only access their 
>>>region (with potential speed restrictions as well, just like video 
>>>memory, but less drastic). Only if there are more than one thread 
>>>accessing the same region (which can only happen because of 
>>>transparency), they would have to be serialized.
>>>Of course, having more than one thread drawing off-screen would be 
>>>great for systems with more than one CPU.
>>      I agree, it's a good solution for tearing, but are you prepared to 
>>up to all that nice effects.
>>      By having this setup, when you move of resize a window you lose 
>>informations(pixels) that this window comes above of. The most 
>>situation is when you move a window because you need to redraw 
>>everything that becomes visible as you move it. Bad!
> I really hope you people understand that tearing (when moving a window 
> say from left to right, while you see the upper part of the window a 
> (few) pixel(s) more advanced to the right than the lower part: at least 
> that's my definition for 'tearing': correct=3F)

        Ours too. :-) B-)

> will =5Fonly=5F be solved by 
> simply syncing the redrawing of the window with vertical retrace! 

        OK, this was something I wanted to ask you about.
        IMHO, you can avoid tearing if you blit the whole window during 
retraces, but, that is done in hardware, and if even the HW is not able 
to eliminate that, what can we do?
        [This can also be applied when copying from mainMem]
        What we can do is, stop the vertical retrace while the engine blits 
that window(or we copy from mainMem) to the new position, then restart 
the vertical retrace process. BUT, will we be able to see something on 
screen while the vertical retrace is stopped? (Screen won't go black?). 
Please don't laugh because I don't know how a graphic card shows pixel 
on screen/monitor.
        IS this possible? Please explain how can we do the blit between 
retraces. Thanks.

> Hence: the doublebuffering of entire screens while only updating the 
> offscreen buffer and flipping between them, then updating the diff to 
> the other buffer, OR just write to the visible framebuffer DURING 
> retrace OR keep synced with the vertical  line counter and prevent you 
> crossing it during drawing (not adviced).

        While I prefer the 2nd solution above the 1st one, I _really_ don't 
understand the 3rd - I'm under impression I even don't have to. :-D


Other related posts: