DirectFB - Home of the pragmatist Roadmap


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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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

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

-- 
Billy Biggs
vektor@dumbterm.net


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



Home | Main Index | Thread Index


directfb.org / Development / Old Archives