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? (syrjala@sci.fi):
> > 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.

What about DSFLIP_ONSYNC and DSFLIP_WAIT.
The old DSFLIP_WAITFORSYNC could be defined as DSFLIP_ONSYNC | DSFLIP_WAIT.
The only combination that wouldn't make sense is DSFLIP_WAIT without
DSFLIP_ONSYNC.

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH


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