On Monday 24 June 2002 10:18, you wrote: > Hi, > > Mike Pieper <[EMAIL PROTECTED]> writes: > > 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. > > I migth be misunderstanding something here, but why don't you use > windows to blend the onscreen GUI over the TV image? This approach > should work perfectly fine and is completely hardware-accelerated > on a Matrox card. I think I expressed it a little bit wrong. What I mean is that I would like to send the video pictures to one layer and have the GUI in another layer. The hardware should do the mixing. But unfortunately on G400 the BES layer hides the primary layer. Therefore I have to do it all with one layer. With 'has to be done by software' I mean that mixing the tv window with the GUI window has to be done explicitely.
In my application I'm using a window for video and several windows for the GUI. Please correct me when I'm wrong, but when I flip the video surface, then I assume that directfb checks which part of the image has changed and redraws the complete window stack in that area. Because the video window takes the complete screen everything has to be redrawn. Redrawing is hardware accellerated as long as the surface is in video memory, or? What I have seen is that this redrawing takes some time. Because redrawing begins right after the sync interrupt and takes so long, I can see the flip on the screen. But maybe I'm making mistakes there. So I'm thankful for every hint how to improve things. Do you think that such a long redraw time is unusual? Did I misunderstood the way how directfb works? Mike -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
