Changes

SurfaceTexture is a unified In Android 2, there were many buffer management mechanism on systems. In Android4, which you can setup it to run in different modeall of this is unified under SurfaceTexture. This is made possible by the great flexibility of SurfaceTexture: sync/async, single/multiple buffer by simple function call which make * SurfaceTexture supports both synchronous and asynchronous modes.* SurfaceTexture be used everywhere in Androidsupports generic multi-buffering: Codec/Camera configure it to can have serveral buffer (based on hardware, 9 for camera preview in Unagi) run asynchronously, Layer rendering configure it to have 2~3 buffer (based on BSP) run synchronously. And since its flexbility, you can encode a OpenGL rendered surface on-the-fly by using SurfaceMediaSource (which implement ISurfaceTexture) which is the core any number of Google Miracastbuffers between 1 and 32.

Examples:* The Codec/Camera code configures it to have several buffers (depending on hardware, for instance 9 buffers for camera preview on Unagi) and run asynchronously* The Android compositor configures it to have 2--3 buffer (depending on [http://en.wikipedia.org/wiki/Board_support_package BSP]) and run synchronously.* Google Miracast uses it to encode OpenGL-rendered surfaces on-the-fly. Let us now describe how the client-server SurfaceTexture system allocates GraphicBuffer's, and how both the client and server sides keep track of these shared buffer handles. Again, SurfaceTexture is the server-side class. , while SurfaceTextureClient is the client-side class. Both store Each of them stores an array of GraphicBuffers, which is called mSlotsin both classes. The GraphicBuffer objects are separate instances in SurfaceTexture and in SurfaceTextureClient, but the underlying gralloc buffer handles are the same. The mechanism here is the as follows. The client side issues a SurfaceTextureClient::dequeueBuffer call to get a new buffer to paint to. If there are is not already enough buffersa free buffer in mSlots, and the number of buffers is not over above the limit (32), it sends an IPC message that results in a call to SurfaceTexture::dequeueBuffer which allocates the a GraphicBuffer. And after buffer allocationAfter this transaction, still inside of SurfaceTextureClient::dequeueBuffer, the client side will send an another IPC message is sent, that results in a call to SurfaceTexture::requestBuffer to get the gralloc buffer handle GraphicBuffer serialized over IPC back to it, using GraphicBuffer::flatten and construct a GraphicBuffer around this handle::unflatten, and cache it into its own mSlots. The mSlots arrays on both sides mirror each other, so that the two sides can refer to GraphicBuffers GraphicBuffer's by index. This allows the client and server side to communicate with each other by passing only indices, without flattening/unflattening GraphicBuffers again and again.