[directfb-users] Re: Binding layers togeather

[Denis Oliver Kropp <dok@directfb.org>]

Quoting Ville Syrjälä:
> On Tue, Sep 30, 2003 at 03:05:29PM +0200, Denis Oliver Kropp wrote:
> > Quoting Ville Syrjälä:
> > > 3. 
> > > Currently the surface buffers are flipped by each layer's FlipBuffers()
> > > method. Obviously flipping them twice would not work. So maybe pass a flag
> > > to FlipBuffers()? I don't think we should move the
> > > dfb_surface_flip_buffers() call to common code because I have plans for
> > > triple buffering which needs to control this stuff in FlipBuffers().
> > 
> > Double flipping wouldn't occur with my above solution, but I'm not sure
> > if it's possible wrt your plans.
> 
> The plan is to only flip the back and front buffers but leave the idle
> buffer alone if the vsync hasn't occured since the last full flip. This
> way no matter how many fps the app does we don't get any tearing.
> Actually I just tried this with CRTC2 and it seems to work with 2D stuff.

I have flickering even in triple buffering if fps is higher than 100,
while the display refresh is 50 Hz. Each frame is cleared and sprites
are blitted to it. Above 100 fps the lower part of the frame flickers.
It looks like after two flips, the front buffer being still displayed is
cleared. The flickering in the lower part implies that the video encoder
was in the process of reading the frame when it got overtaken by the clear.

> But for some reason DRI isn't happy with this. I see black horizontal
> bands that I would say are because the buffer is cleared while it's being
> displayed. But I don't really understand how that can happen. I can
> however get perfect output if I simply do nothing instead of flipping the
> back and front buffers. But this means that when severals flips are called
> during one field the oldest will be the one displayed when the flip
> actually occurs.

Maybe the DRI problems are the same as my problem described above.

> > > 4.
> > > Vsync handling is quite problematic and maybe the only reason master/slave
> > > terms should be used. That is master will the only one doing any vsync
> > > waiting.
> > > The other approach might be that we first get the  current vsync count
> > > from all but one layer and then that layer waits for vsync. After which we
> > > would check if the next layer has gone past the vsync and wait if
> > > necessary and so on. Obviously that can guarantee good result only if
> > > DSFLIP_ONSYNC is used and all the layers really support it. Quite messy
> > > really...
> > 
> > Hmm, even harder to fit into my solution...
> 
> I don't think there's a real need that complex solution. Just waiting on
> one layer should be good enough. But waiting on all layers sounds bad.
> Currently with dfbmga I wait for the vsync on CRTC2 if both layers are
> used. This works fine because CRTC2 has a slower refresh rate than
> BES and BES supports DSFLIP_ONSYNC.

Each layer should follow as many flips as possible, asynchronously while the
surface is being flipped at its full refresh rate.

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH


-- 
Info: To unsubscribe send a mail to ecartis@directfb.org with 
"unsubscribe directfb-users" as subject.