[haiku-appserver] Re: drawing thread

Hi,

> Axel D=F6rfler wrote:
> > When you have a setup like this, all threads could even 
> > simultaneously 
> > access the main memory, since they will all only access their 
> > clipping 
> > 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 
> give 
> 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 
> drastic 
> 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) will =5Fonly=5F be solved by 
simply syncing the redrawing of the window with vertical retrace! 

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

Rudolf.

Other related posts: