[haiku-appserver] Re: drawing thread
- From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Sun, 24 Oct 2004 21:19:04 +0200 CEST
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:
