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, Dec 08, 2002 at 06:32:18PM +0500, Antonino Daplas wrote:
> 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:

Ok so we agree.

> 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

Ah I see we understand sync vs. async the oppostite ways. You use the
terms from the perspective of the display device while I think about the
calling process.

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

You'd still need a signal to notify the process that it's safe to decode
the next frame.

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

Yes I just use CreateSurface w/o specifying where the surface goes. This
way DirectFB will take care of copying the data to video memory when I
request a blit to the back buffer. And since I never touch the surface
with anything but Lock/Unlock the copy in system memory is always up to
date and there's no need to copy it back from the video memory. At least
that's what I hope is happening :) And if and when we get proper AGP
surface support the same code should work but with added speed.

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

Ok so we're doing pretty much the same thing.

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

You may be right. Altough I'm still a bit sceptical because you need a
signal of some sort to notify you that the flip has actually occured.

Perhaps we should just let the programmer worry about the signal and keep
the DirectFB part very simple. So we just need a new DSFLIP_ASYNCHRONOUS
(from the calling process' pov) And possibly a new layer capability flag
DLCAPS_ASYNCHRONOUS_FLIP or something like that.

Ville Syrjälä

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

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