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.