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

Quoting Mike Pieper (
> On Monday 24 June 2002 10:18, you wrote:
> > Hi,
> >
> > Mike Pieper <> writes:
> > > 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.
> >
> > 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

> 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 |
|                 |

                            Convergence GmbH

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

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