|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 (email@example.com): > > 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? The hardware sends out top field, then bottom field, then top field, etc to the television in sequence. If you page flip during the VBI after a bottom field, then the top field of the new buffer will be shown next, then the bottom field of that buffer, then the top field, etc. So yeah, if I say 'hey hardware, here's a frame' and then idle for a minute, the hardware will loop through showing the top and bottom fields of that frame. If the stream was interlaced, then motion will jump back and forth in time for that whole minute :) To be honest I don't know about this does the page flip happen immediately, or on the next scanline, or during the next VBI? Making sure this is done at the right time might solve Brian's problem... I'm pretty sure he wants the flip to occur during the VBI between the bottom field and the top field, either by queueing this before the VBI happens, or waiting until the VBI occurs and then doing an immediate flip. > 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. Even without the preemptive/low-latency patches this is much rarer than you think (hardware dependant of course, but very unlikely that it would be screwing up Brian as much as he's getting messed up). > 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. Trust me that this is not happening either. Latency issues are not as bad as they think you are in 99% of cases. > > 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. I just wanted to make clear the distinction. :) I think we all can agree that having asynchronous page flipping primitives would be very awesome and useful, even in this case. -- Billy Biggs firstname.lastname@example.org -- Info: To unsubscribe send a mail to email@example.com with "unsubscribe directfb-dev" as subject.