|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga
Quoting Ville Syrj?l? (email@example.com): > > 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 firstname.lastname@example.org with "unsubscribe directfb-dev" as subject.