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

On Sun, 2002-12-08 at 13:26, Ville Syrjälä wrote:
> On Sun, Dec 08, 2002 at 03:53:48PM +0500, Antonino Daplas wrote:
> > 
> > In effect, the backend (in this case, DirectFB) has nothing to do but
> > display the frame, and to make it pleasurable for the viewer, do the
> > flips during the sync pulse. Since Mplayer already guarantees that each
> > frame is delivered at the correct time, waiting for vsync is needed only
> > for hardware incapable of synchronous flips.
> Consider the following:
> 1. Flip() is called sometime during one frame
> 2. Next frame is being decoded into the new back buffer
> 3. vsync happens and the flip actually happens
> In step 2 we've been decoding into the buffer that was still displayed.
> The result is tearing.
> To avoid this you need to use triple buffering or make sure the flip has
> actually happened before you touch the new back buffer.
Right :) Perhaps I wasn't clear enough, and I never said you were
wrong.  I said earlier that for hardware capable of synchronous flips,
you have the option to wait for vsync, or not wait at all.  The
difference between synchronous flips/asynchronous flips is the ordering:

case 1: asynchronous hardware flips:

request flip->wait for vsync ->program registers

case 2: synchronus hardware flips

request flip -> program registers -> wait for vsync/not wait at all

In case 2, when you only have a double buffer, you still do useful work
while waiting for the vsync instead of the whole time idling the cpu (as
in case 1).  Not much to be gained here but perhaps a few % difference,
but you give Mplayer extra processing time. The difference will probably
even out in the end, anyway.

The real advantage is if you have a kind of triple buffering scheme
(which is your argument).  If this is the case, there is no need to wait
at all.  I have actually modified vo_directfb.c to process to a temp
buffer in system memory which is copied later to the backbuffer. (You've
mentioned that this is what you're doing, right?).  I also have the
added advantage that the backbuffer and frontbuffer are in AGP memory,
so copying from temp to backbuffer is very fast.  Then in the driver
level, I just swap the front and backbuffer pointers. This isn't exactly
triple buffering but the same scheme used by Xvideo. It's  good enough
that I actually get smooth displays with low cpu usage. 

Anyway, my point in this thread is that, depending on the hardware, you
can choose to program the registers before or after waiting for vsync. 
And secondly, there might be useful need for further differentiation of
the DSFLIP_WAITFORSYNC flag, and it's not too difficult to apply it in
software if the hardware is capable of doing so.


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

Home | Main Index | Thread Index / Development / Old Archives