On Fri, 2010-02-05 at 14:06 +0100, Niels Roest wrote: > Matthew Hails wrote: > > I have an existing graphics library for an embedded system, and I would > > like to provide an implementation of the API using DirectFB. However, > > there are two features that I haven't yet been able to work out how to > > do using DirectFB: > > > > 1. Provide a double-buffered interface to a graphics layer that exposes > > full draw/read/write capabilities of the visible (front) buffer as > > well as the hidden (back) buffer. From my reading so far of the > > DirectFB API, all drawing operations are on the hidden (back) buffer > > of a double-buffered surface, and the only access to the contents of > > the visible (front) buffer is read-only access via > > IDirectFBSurface::Lock(). I can't see a way to, for example, blit > > from an off-screen surface directly onto the visible buffer of a > > surface. > > > Correct, this is on purpose. > Normally, if you do double buffering, you want DirectFB to do the buffer > handling itself.
True. But the application using the API uses double buffering for general smoothness, but writes to/from the visible buffer for efficiency in a few cases. It makes a big difference in performance in these cases. > two scenarios come to mind: > (1) draw to the back buffer and do a flip with the updated region. This > does a copy from back to front (potentially accelerated). > (2) if you really want to have the front buffer to be "newer" than the > back buffer, I suggest to program the flipping yourself: allocate two > single-buffer surfaces. Note that this will not allow you to swap the > surfaces if on a flip a buffer swap would be possible (via e.g. "pan" in > the fbdev driver). Ok, thanks very much for this. I don't think either of these are realistic for my purposes, but it gives me the info and some options. > > 2. Provide a multiple buffered graphics layer with 4 buffers. I see > > that it's possible to pass the DLBM_TRIPLE flag to > > IDirectFBDisplayLayer::SetConfiguration(), but I would like to use > > 4 buffers. > > > A thought for some time is to extend the surface handling to allow any > number of buffers, and to change this dynamically. Any takers? :) > Not possible yet though. Ah, ok. (Maybe if I actually do the port to DirectFB ...) Many thanks for your reply. Matt. _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
