DirectFB - Home of the pragmatist Roadmap

[directfb-dev] Re: TV oriented application needs; was:ANNOUNCE: DirectFB
Mailing List archive

[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 ( 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.


Info:  To unsubscribe send a mail to with
"unsubscribe directfb-dev" as subject.

Home | Main Index | Thread Index / Development / Old Archives