Hi Mathias, - It seems to me that clients of SurfaceFlinger don't care about memory allocation and that accesses to surfaces are via GGLSurfaces, which just contain a pointer (not a base/offset combination). For a client, access to this pointer is gated through the surface lock/unlock calls. So clients should be O.K. regardless of how the surface memory is allocated.
- It's a little less clear where SurfaceFlinger is called - does it access the surfaces in the same way as a client (i.e. through a lock/unlock) or does it just grab hold of the pointer (base/offset) and use it as it sees fit. - w.r.t. complexity, The scenario I'm trying to get to should be simpler and not need a surface heap. - I can see where I would need to allocate my Surface (in LayerBitmap) - and store a relevant handle in the shared control block. - I can see where I would map my Surface into client space (in the lockSurface call in SurfaceComposerClient) using the handle in the control block. - Where I see more difficulties is in SurfaceFlinger, which rather than propogate a buffer pointer around the place a base/offset gets bounced around. e.g. in things like the copybit_image_t struct. (I also notice that this struct doesn' contain a stride - so it begs the question as to whether SF honours the stride associated with the buffer? - Is there any reason wht SF couldn't just propogate a simple pointer around (rather than a base/offset - which is only relevant for allocation purposes)? On Thu, Jan 22, 2009 at 11:31 PM, Mathias Agopian <[email protected]>wrote: > > On Thu, Jan 22, 2009 at 3:04 PM, F H <[email protected]> wrote: > > > > It goes back to my desire to use my own allocator for surface memory. > > I have a degree of enthusiasm to do this because many of our own > > underlying components (e.g. OpenGL ES, Video Codecs, Blit engines and > > so on) use our own abstraction rather than a heap. So when a Surface > > is to be allocated I need SurfaceFlinger to allocate one of these > > buffers (and map it into SurfaceFlinger's address space) and pass back > > information to the client who then needs to use this handle to make an > > ioctl call to map the related buffer memory into the user client > > space. > > I see. Well this is complicated, basically you're trying to work > around the current design and I'm not very comfortable with this. > You're looking for an abstraction of mmap basically, which we don't > have. So you'll have to build your own "everything" parallel to the > current mechanisms. I don't have enough information about your system. > > Personally I would advise against going this route for now. > > Mathias > > > > > > On 1/22/09, Mathias Agopian <[email protected]> wrote: > >> > >> On Thu, Jan 22, 2009 at 2:46 PM, F H <[email protected]> wrote: > >>> > >>> Thank you Mathias, > >>> > >>> Very helpful as usual. > >>> > >>> If I wanted to convey a bit more information between SurfaceFlinger > >>> and the client, would it be best to convey it via the control block or > >>> add it to the Parcel? > >> > >> Can you elaborate? What information? > >> > >> Mathias > >> > >>> > >>> Fred. > >>> > >>> On 1/22/09, Mathias Agopian <[email protected]> wrote: > >>>> > >>>> 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 -~----------~----~----~----~------~----~------~--~---
