|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 Mon, 2002-12-09 at 05:15, Billy Biggs wrote: > 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. > Yes, I see the reasoning here. > So, in both of these cases, we require very accurate flipping, or > information about which field is being shown. Yes. As you've said, this kind of display requires very accurate flipping, the main reason why I ask how he waits for the vsync. Correct me if I'm wrong. I assume waiting for vsync is the signal point when to start displaying the frame, after which, the hardware takes care of displaying field1 and field2. Field1 gets displayed almost immediately, and Field2 will get displayed some time later depending on the TV system, ie, 20ms for PAL. Is this correct? Or maybe field2 is also synced on the next TV signal? Waiting for vsync by sleeping on an interrupt may mess up your timing entirely because of latency problems, as I've mentioned in the other thread. In addition, when an interrupt occurs, it can take as much as a few thousand cpu cycles to enter and another few thousand to exit. This is for ix86 hardware. So, if the vsync waiting gets delayed by only 20ms, that's an entire field interval already. So perhaps, he can test the registers directly for arrival of the vsync instead and see how that pans out. This will more or less guarantee accurate timing. 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. > This thread kinda digressed a little. The async flipping part is for personal consumption :-). I will only dare use it on a frame-based stream which is less prone to timing errors, and where the frontend guarantees the timing. Tony -- Info: To unsubscribe send a mail to email@example.com with "unsubscribe directfb-dev" as subject.