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

[Billy Biggs <vektor@dumbterm.net>]

Antonino Daplas (adaplas@pol.net):

> For apps, on the other hand, which are throttled (a video player
> requesting flips at a stately pace of 25-30/sec) and your display
> device is capable of doing more than that, then you are pretty much
> guaranteed that the flip will occur before the arrival of the next
> frame, which negates the need to wait for the arrival of the vsync.
> The only thing left for the driver to do is guarantee that it occurs
> during the vsync pulse, and that is where synchronous hardware flips
> come into play (This is async_flip in the perspective of the
> software).

  Actually, the problem with tearing we're describing is worse.  In
Brian's case, he's playing a 29.97fps video on a 59.94hz display, and
since the source is interlaced, he requires that page flips are done on
specific retraces.  Since the frames he's blitting are top-field-first,
he _must_ queue the request to page flip while the bottom field of the
previous frame is being displayed.

  In the case of tvtime, we run in interlaced single buffer mode.  So,
while the top field is being shown, we're writting to the bottom field
of the same buffer.  No page flips at all.

  So, in both of these cases, we require very accurate flipping, or
information about which field is being shown.

  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.

-- 
Billy Biggs
vektor@dumbterm.net


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