|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 06:44, Billy Biggs wrote: > Antonino Daplas (firstname.lastname@example.org): > > > > 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. > Okay. It's clearer now, thanks. > > 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. Okay, I'll close this issue then. It's just something that keeps nagging me since I was bitten by this once (different issue altogether) with an IRQ handler. The effects though were highly irregular and infrequent, so this is probably not the case. > > > > 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. > That and an AGP surface... :-) Tony -- Info: To unsubscribe send a mail to email@example.com with "unsubscribe directfb-dev" as subject.