|Site sponsored by IGEL|
[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. Tony -- Info: To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe directfb-dev" as subject.