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 -~----------~----~----~----~------~----~------~--~---
