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

Quoting Ville Syrj?l? (
> > 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.

The following only applies to the specified circumstances:
If you specify DSLF_READ you will lock the system memory instance, but
write only goes into video memory directly (surfaces.c: 490). And after
writing to video memory you never will get the system instance again.

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

The only combination that wouldn't make sense is DSFLIP_WAIT without

Best regards,
  Denis Oliver Kropp

| DirectFB - Hardware accelerated graphics |
|                 |

                            Convergence GmbH

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

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