Thanks Mathias, With respect to video playback and LayerBuffers:
- is it the client who allocates the buffer or does surface flinger allocate these at some point for the client to then use. - I don't understand your PMEM driver comment - are you saying that the client creates his own heap and own buffers using the PMEM device and that this is a different heap used by surface flinger's buffer allocation. - which APIs have become exposed and do you mean exposed to Applications developers as opposed to things in the platform? When I play a video, I see one call to registerBuffers and lots to post a buffer - do I infer from this that the client has created only one buffer and is continually re-posting it? On Fri, Feb 6, 2009 at 8:21 PM, Mathias Agopian <pixelflin...@google.com>wrote: > > Hello, > > On Fri, Feb 6, 2009 at 5:36 AM, F H <expelia...@googlemail.com> wrote: > > > > Hi Mathias! > > > > Can you outline how LayerBuffers are intended to work in SurfaceFlinger. > > They are layers that get the content from "somewhere else". The > content is pushed from an external entity as it becomes ready. > > > - Are these buffers still allocated by SurfaceFlinger? > > no. > > > - Does it enable for example multiple buffers to be queued for display > > (rather than a double buffered approach). > > yes and no. SurfaceFlinger always displays the most recent buffer > next. So if 5 buffers are pushed in a row, only buffer 5 will be shown > at the next update (next frame). > > > - Is the intention of them to provide support for streams of video > > data (e.g. from decoded video). > > yes. > > > - Is the intention that these buffers will get locked/unlocked and > > drawn to by a client, or does Android differentiate between surfaces > > used for general rendering and those used for say video playback. > > no. It is an error to call lock/unlock on these surfaces. > > > - With respect to video playback does Android expect to be able to say > > decode a video frame and then allow for example some rendering to be > > added to the buffer before being presented for display? > > no. > > > - Can you describe how video playback relates to SurfaceFlinger? > > The video decoder produces buffers which it pushes to SurfaceFlinger > via ISurface. All these APIs are private. And in cupcake we added a > permission to have access to this API (we should have done it before, > it was an oversight). > In order to be h/w accelerated, these buffers have to be allocated > "properly", otherwise, surfaceflinger reverts to software rendering. > Currently there is only one proper way to allocate them, and it's to > use the pmem driver. > No need to mention that these APIs are far from being set in stone. > > > - What mechanisms are used to ensure that video frames are displayed > > at the correct time by SurfaceFlinger? > > None. The most recent buffer is displayed as soon as possible, > typically within the next 16 ms. > > mathias > > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
