[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga

[Antonino Daplas <adaplas@pol.net>]

On Mon, 2002-12-09 at 06:44, Billy Biggs wrote:
> Antonino Daplas (adaplas@pol.net):
> 
> > > So, in both of these cases, we require very accurate flipping, or
> > > information about which field is being shown.
> > 
> > Yes. As you've said, this kind of display requires very accurate
> > flipping, the main reason why I ask how he waits for the vsync.
> > Correct me if I'm wrong.  I assume waiting for vsync is the signal
> > point when to start displaying the frame, after which, the hardware
> > takes care of displaying field1 and field2.  Field1 gets displayed
> > almost immediately, and Field2 will get displayed some time later
> > depending on the TV system, ie, 20ms for PAL. Is this correct? Or
> > maybe field2 is also synced on the next TV signal? 
> 
>   The hardware sends out top field, then bottom field, then top field,
> etc to the television in sequence.  If you page flip during the VBI
> after a bottom field, then the top field of the new buffer will be shown
> next, then the bottom field of that buffer, then the top field, etc.
> 
>   So yeah, if I say 'hey hardware, here's a frame' and then idle for a
> minute, the hardware will loop through showing the top and bottom fields
> of that frame.  If the stream was interlaced, then motion will jump back
> and forth in time for that whole minute :)
> 
>   To be honest I don't know about this does the page flip happen
> immediately, or on the next scanline, or during the next VBI?  Making
> sure this is done at the right time might solve Brian's problem...  I'm
> pretty sure he wants the flip to occur during the VBI between the bottom
> field and the top field, either by queueing this before the VBI happens,
> or waiting until the VBI occurs and then doing an immediate flip.
> 
Okay.  It's clearer now, thanks. 

> > Waiting for vsync by sleeping on an interrupt may mess up your timing
> > entirely because of latency problems, as I've mentioned in the other
> > thread.
> 
>   Even without the preemptive/low-latency patches this is much rarer
> than you think (hardware dependant of course, but very unlikely that it
> would be screwing up Brian as much as he's getting messed up).
> 
> > In addition, when an interrupt occurs, it can take as much as a few
> > thousand cpu cycles to enter and another few thousand to exit.  This
> > is for ix86 hardware. So, if the vsync waiting gets delayed by only
> > 20ms, that's an entire field interval already. So perhaps, he can test
> > the registers directly for arrival of the vsync instead and see how
> > that pans out.  This will more or less guarantee accurate timing.
> 
>   Trust me that this is not happening either.  Latency issues are not as
> bad as they think you are in 99% of cases.

Okay, I'll close this issue then.  It's just something that keeps
nagging me since I was bitten by this once (different issue altogether)
with an IRQ handler.  The effects though were highly irregular and
infrequent, so this is probably not the case.

> 
> > > Having asynchronous flipping is acceptable so long as you have high
> > > precision timing.  In Brian's case, he must make sure that he only
> > > queues a page flip when the bottom field has been shown from the
> > > last frame.  If he's too quick, then he'll end up writing the next
> > > frame and not knowing that his previous flip hasn't happened yet.
> > 
> > This thread kinda digressed a little.  The async flipping part is for
> > personal consumption :-).  I will only dare use it on a frame-based
> > stream which is less prone to timing errors, and where the frontend
> > guarantees the timing.
> 
>   I just wanted to make clear the distinction. :)   I think we all can
> agree that having asynchronous page flipping primitives would be very
> awesome and useful, even in this case.
> 
That and an AGP surface... :-)

Tony




-- 
Info:  To unsubscribe send a mail to listar@directfb.org with 
"unsubscribe directfb-dev" as subject.