|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga
Antonino Daplas (firstname.lastname@example.org): > For apps, on the other hand, which are throttled (a video player > requesting flips at a stately pace of 25-30/sec) and your display > device is capable of doing more than that, then you are pretty much > guaranteed that the flip will occur before the arrival of the next > frame, which negates the need to wait for the arrival of the vsync. > The only thing left for the driver to do is guarantee that it occurs > during the vsync pulse, and that is where synchronous hardware flips > come into play (This is async_flip in the perspective of the > software). Actually, the problem with tearing we're describing is worse. In Brian's case, he's playing a 29.97fps video on a 59.94hz display, and since the source is interlaced, he requires that page flips are done on specific retraces. Since the frames he's blitting are top-field-first, he _must_ queue the request to page flip while the bottom field of the previous frame is being displayed. In the case of tvtime, we run in interlaced single buffer mode. So, while the top field is being shown, we're writting to the bottom field of the same buffer. No page flips at all. So, in both of these cases, we require very accurate flipping, or information about which field is being shown. Having asynchronous flipping is acceptable so long as you have high precision timing. In Brian's case, he must make sure that he only queues a page flip when the bottom field has been shown from the last frame. If he's too quick, then he'll end up writing the next frame and not knowing that his previous flip hasn't happened yet. -- Billy Biggs email@example.com -- Info: To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe directfb-dev" as subject.