Hi, On Tue, Jan 20, 2009 at 3:37 AM, F H <[email protected]> wrote: > Hi Mathias, > > Android typically creates two buffers per surface. Presumably this is so > that one of them can be locked by an application for rendering while the > other (complete buffer) is available to SurfaceFlinger for compositing?
correct. > What kinds of surfaces would have only one associated buffer? Surfaces with content that never changes? :-) But why do you ask? SurfaceFlinger never allocate a surface with only 1 buffer. > Surface Buffer access is guarded by calls to Lock/Unlock(andPost) - there is > another fcunction - nextBuffer which looks like it always returns data > pertinent to the front buffer without effecting a lock. nextBuffer() was an experiment which was never cleaned-up. Don't use it (I mean it). nextBuffer will most likely disapear in cupcake. > Are all accesses to buffers gated through either lockSurface (& > corresponding unlock..) correct. > or nextBuffer? When is nextBuffer used as opposed to > the lockSurface? (Seems like a misleading name). see above. > Does the information ultimately get conveyed to a GGLSurface object before > any Android rendering is done? I need to double-check on that. I think this might still be the case. > I also noticed a limit on the number of Layers a client can have > (NUM_LAYERS_MAX), which is set to 31. Does this pose a problem for > applications that for example use lots of UI type widgets? No. A "layer" correspond to a "window" in the UI (like a status-bar, a dialog, or the main window). > Also I guess 31 > is used as a number just so that the control block stays smaller than 4k? Yes. It also simplifies a few things to keep track of surfaces (the implementation uses an uint32 as a bit set). Mathias > > Thanks, > Fred. > > > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
