|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: TV oriented application needs; was:ANNOUNCE: DirectFB 0.9.12
On Thursday 20 June 2002 02:21, you wrote: > The current state of the flip/vsync stuff is definitely unsatisfying. > Expect a reasonable behaviour for the next release, any input on > application needs would be helpful. Well, my application (df-gp.sf.net) also has the problem that the wait for sync is not sufficient. The application shows full size TV pictures (PAL 720x576) with possible overlays on it. Because it's not possible to mix several layers by hardware (I'm using a G400), it has to be done by software. If I specify the wait-for-sync flag, then I've seen that the program waits until the sync signal comes and then it begins to compute the resulting image. The more overlays I have, the longer it takes. At the end one can see a cut in the picture when it really flips. And this cutting line is moving when the amount of overlays changes. The expected behavior would be that a flip with wait-for-sync would schedule the changes, which were currently made on the back-buffer, for the next picture on the screen. That means the picture should be computed immediately, but should be shown on the next sync. When I see this right then this would mean, that the layers primary surface itself is double buffered. All other surfaces are double buffered to. The primary layers flipping is synchronized to the vertical retrace. Every other surface can be flipped anytime when some changes are finished. Flipping a non-primary surface means painting on the layers' primary surfaces back-buffer. This should be deferred when the next primary layer flip is near to come and it's not enough time to perform the complete painting. Because it's difficult to know when the next background flip comes, it could be a good idea to defer every flip of a non primary surface until the primary layer has been flipped. Immediately after the flip all scheduled operations are performed and the back-buffer is ready for the next flip. While all new flip requests are again collected for execution after the next primary surface flip. If there was no change request, then the primary surface don't have to be flipped on the next retrace (the picture obviously didn't change). Does someone understand me? :-) This behavior should be inside the system, so that it is compatible with gtk on directfb. I mean, when I think about, it's perhaps possible to implement this behavior, but a surface, which is created by the gdk-engine doesn't know about that and would not respect the synced operations. My current solution in df-gp is to send the video to an extra surface. Flipping is done without wait-for-sync, but after flipping the G400 is resynced, i.e. the output timers are restarted. Therefore I can't see the 'cut' on the TV screen. The cut still moves of course (with respect to the amount of overlay), but keeps mostly in a part of the picture where it can't be seen. This resyncing throws another light on the surface flipping theme. Most applications try to sync against the graphics card. In a TV application I have the problem that the TV stream has its own timebase and I need to bring the picture flow to the TV without losing a picture or doubling a picture. But when the graphics card runs freely this isn't possible. It would be ok, if the graphics card refresh frequency is much higher than the TV rate, but when the graphics output goes to the TV again, we have the worst case. The output frequency is near the input frequency and after a while the flipping points will clash together and I have to skip a picture or to double it. The simple idea in this case is, to take the TV input stream as the timebase and to sync the graphics card against this timing (a software gen-lock). I don't know of any graphics card which allows such behavior. I've tried to implement that for the G400, but I'm not able to fine tune the output frequency to get the desired effect. Instead I do a hard counter reset every some seconds and in the meanwhile all runs freely. Because the frequencies are nearly the same this is ok (for some seconds). For directfb this would mean that for a synchronized primary layer flipping, there should be the option to use the graphics card vsync interrupt _or_ to use a user provided clock. Mike -- Info: To unsubscribe send a mail to email@example.com with "unsubscribe directfb-dev" as subject.