[haiku-appserver] Re: drawing thread

Hi :)

>       What's =3F? What about =5F? :-)) No, really.
Oops.. I guess wrong character set somehow: there should be some 
underscores and question marks in their place :)

> > 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-)
OK, thanks for confirming that!

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

Eh: this will work. Only you have to sync to retrace yourself. And of 
course: the BIG downside of only doing this on retraces is that the 
engine can't be used much in time. If a retrace would cost say 10mS 
while the screen scan costs 90mS then you would only be able to use the 
engine for 10 percent of the time!

HOWEVER: using fullscreen double buffering solves the 10% issue: you 
may of course blit 100% of the time in a visible buffer IF this buffer 
is used as SOURCE only (dest should be the offscreen buffer, that goes 
onscreen after the next retrace).

General speaking: you should NEVER change the visible memory content 
during screen scan. Not for blits, not for video, not for games. If you 
do: you will enjoy tearing always. The visibility of the tearing is 
determined by a number of factors like:

->dest location is not same as source location on screen (moving a 
window) gives worse tearing from dest == source
->if (new content / old content) contrast change is bigger, tearing is 
more visible.
->if screen refresh is lower, tearing will be more visible
->if screen is built in  the 'interlaced'  way (TVout!) it will be more 
visible than in progressive scan.

Anyway: you get the point. BTW: ALL these examples are verified by me 
personally a few years ago (BeTVOut testing)


>       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.
NO WAY!!! forget that please. Theoretical impossible. (monitor requires 
'fixed' timing always)

> BUT, will we be able to see something on 
> screen while the vertical retrace is stopped? (Screen won't go 
> black?). 
Don't even THINK about doing this! :)

> Please don't laugh because I don't know how a graphic card shows 
> pixel 
> on screen/monitor.
I don't laugh. I can understand this, I could ask the same question if 
I didn't know. Besides: I am probably asking strange things myself 
every now and then :-)

As soon as you mess with this timing you will get into big-time 
trouble. Both the card and the monitor definately won't like this a 
bit.

>       IS this possible? Please explain how can we do the blit between 
> retraces. Thanks.
->NOT possible
->do a waitForRetrace()
->now blit and hope the engine finishes before the screen starts 
drawing again (you can't guarantee this. you WILL get into trouble at 
SOME point.)

Only good solution: double buffering entire screen and blit to 
offscreen memory only, then switch offscreen onscreen during retrace, 
then blit now onscreen memory to now offscreen buffer. Repeat when 
needed. 8-)


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

I was just mentioning that for completeness sake: you know: I actually 
use that ATM in the nVidia driver to prevent the cursor from tearing on 
moving it. Bad hardware :-/ (Matrox takes care of cursor tearing 
internally)

I use it in the nVidia driver to have the max time avaible to do the 
move. Much better solution: double buffer coordinates and move cursor 
only during retrace (via the kerneldriver INT routine).
Coming up when I have time to spare ;-)
(of no concern of you guys: just an internal matter for me)


Bye!

Rudolf.

Other related posts: