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.