[MPlayer-DOCS] [PATCH] DOCS/tech/tearing.txt
Rich Felker
dalias at aerifal.cx
Fri Jul 1 04:01:30 CEST 2005
On Thu, Jun 30, 2005 at 07:06:10PM +0300, Oded Shimon wrote:
> On Thu, Jun 30, 2005 at 08:55:09AM -0700, Loren Merritt wrote:
> > On Thu, 30 Jun 2005, Diego Biurrun wrote:
> > >On Tue, Mar 08, 2005 at 12:07:23AM +0100, Diego Biurrun wrote:
> > >>On Mon, Mar 07, 2005 at 04:44:21PM +0200, Oded Shimon wrote:
> > >>>What happens with tearing is that halfway through this process, the
> > >>>image changes - a very likely event. Because of this, the monitor
> > >>>displays the first half the first image, and the next half it shows the
> > >>>new image, thinking it's all the same image. The mistake will be
> > >>>"corrected" in the very next refresh, as then the entire screen will be
> > >>>the new image - too slow. Our eye already caught the mistake. With
> > >>>extremely high refresh rates (150hz+), tearing is practically
> > >>>unnoticeable.
> > >>
> > >>I'm not particularly fond of this paragraph. It could be slightly
> > >>clearer.
> > >>Sorry for not being more specific right now..
> > >
> > >I must admit I don't get the above paragraph 100%, can somebody
> > >elaborate? Rich?
> >
> > A CRT doesn't display a whole image at once. It updates one row, and then
> > the next row, and so one until the bottom of the screen, and then jumps
> > back to the top ("v-sync") and continues. So at any instant, the top
> > portional of the screen is from one image, and the bottom portion is from
> > the previous image.
>
> This is nonsense. (hmm, i'm starting to talk like Rich.. :) The entire
> monitor is completely BLACK, _except_ for the horizantel line it's drawing.
Well.. It still has residual charge, but it's in the 'fading' state,
yes.
Rich
More information about the MPlayer-DOCS
mailing list