|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-users] Re: Binding layers togeather
Quoting Ville Syrjälä: > On Mon, Sep 29, 2003 at 10:46:24PM +0200, Denis Oliver Kropp wrote: > > Quoting Jiri Svoboda: > > > Hi, > > > do You plan implement layer binding - in particular sharing buffers beween > > > layers? > > > > Interesting idea, makes me think about IDirectFBDisplayLayer::SetSurface(), > > which doesn't look like the best solution in my eyes. > > I've thought about doing this at some point since wasting video ram is > bad (TM). But I'm not sure what the best API would be. SetSurface() does > seem a bit problematic since it would be possible to call it with any > surface. Another question is if the surface has to satisfy the configuration or if the configuration of the layer is adapted to it. > As far as implementation is conserned I see a few problems: > > 1. > If we're going to share the surface GetDisplayLayer() should not fail for > the second layer if we run out of video ram. That would mean delaying the > surface allocation. Possibly wait until GetSurface() or CreateWindow() is > called. Or the second layer would need to be acquired in a different way. > IDirectFBDisplayLayer::GetBoundDisplayLayer()? I don't really like the > master/slave terms because the only shared thing should be the surface. Delaying the surface allocation is rather important. Allocating video memory when a layer is enabled via GetDisplayLayer() is bad. After committing a lot of changes I made to the layers core (adding DLBM_WINDOWS) we should add another buffer mode being the default, that is DLBM_NONE. For the curious, DLBM_WINDOWS will be a buffer mode where the layer has no surface and the hardware is aware of each window. > 2. > Flip() needs to know all layers related to the surface. Maybe add a list > of layers to CoreSurface? That's not required. There's a global surface reaction which is installed by the layer core, it's called _dfb_layer_surface_listener(). A global reaction is a callback that is executed synchronously by the process which dispatches the notification. We should add the driver call there. > 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. > 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... -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe directfb-users" as subject.