Quoting Mike Pieper ([EMAIL PROTECTED]): > 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.
We are using DirectFB this way for interactive television if hardware has no alpha blending between layers but a fast TMU ;) Even G200 cards are able to handle 50 window stack redraws per second with alpha transparent windows over video windows. Did you try using a YUV window (non-planar) for the video? If you don't need alpha transparency between graphics and video you can use destination color keying with the BES, putting the graphics into the primary layer like Xv always does. > 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? You are right. The flipping region passed to the Flip() call is the region that gets redrawn by blitting the windows together. It's done by a recursive function "update_region" that only blits the visible parts. If a window is opaque the background and windows below are discarded. Do avoid flickering caused by transparent windows the desktop is double buffered by default. After recomposition the region on the desktop gets flipped. If it's a part it gets blitted from the back to the front buffer. If it covers the whole screen the layer gets flipped by swapping these buffers. > 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. The vsync waiting should happen after redrawing just before the flip on the layer surface. An optimized version could wait for the last line of the update region being displayed on the screen if a part is blit-flipped. > 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? You can calculate the redraw time using the MPixel/sec values from df_dok. > Did I misunderstood the way how directfb works? Doesn't seem so ;) -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
