Changes

* The SurfaceFlinger (the Android compositor ) configures it to have 2--3 buffer (depending on [http://en.wikipedia.org/wiki/Board_support_package BSP]) and run synchronously.

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. Each of them stores an array of GraphicBuffers, which is called mSlots in both classes. The GraphicBuffer objects are separate instances in SurfaceTexture and in SurfaceTextureClient, but the underlying buffer handles are the same. The mechanism here is as follows. The client side issues a SurfaceTextureClient::dequeueBuffer call to get a new buffer to paint to. If there is not already a free buffer in mSlots, and the number of buffers is under the limit (e.g. 3 for triple buffering), it sends an IPC message that results in a call to SurfaceTexture::dequeueBuffer which allocates a GraphicBuffer. After this transaction, still inside of SurfaceTextureClient::dequeueBuffer, another IPC message is sent, that results in a call to SurfaceTexture::requestBuffer to get the GraphicBuffer serialized over IPC back to it, using GraphicBuffer::flatten and GraphicBuffer::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 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.

Again, SurfaceTexture is the server-side class, while SurfaceTextureClient is the client-side class. Each of them stores an array of GraphicBuffers, which is called mSlots in both classes. The GraphicBuffer objects are separate instances in SurfaceTexture and Let us now describe what happens in SurfaceTextureClient, but the underlying buffer handles are the same. The mechanism here is as follows. The client side issues a SurfaceTextureClient::dequeueBuffer call to get a new buffer to paint to. If when there is not already a no free buffer in mSlots, and the number of buffers is not above has already met the limit (32e.g. 3 for triple buffering). In this case, it sends an IPC message that results in a call to the server side (SurfaceTexture::dequeueBuffer which allocates ) will wait for a GraphicBuffer. After this transactionbuffer to be queued, and the client side waits for that, still inside of so that SurfaceTextureClient::dequeueBuffer, another IPC message is sent, that results in will not return until a call to SurfaceTexture::requestBuffer to get the GraphicBuffer serialized over IPC back to it, using GraphicBuffer::flatten and GraphicBuffer::unflatten, and cache it into its own mSlots. The mSlots arrays buffer has actually been queued on both sides mirror each other, so that the two sides can refer to GraphicBuffer's by indexserver side. This is what allows the client SurfaceTexture to support both synchronous and server side to communicate asynchronous modes with each other by passing only indices, without flattening/unflattening GraphicBuffers again and againthe same API.

When Let us now explain how synchronous mode works. In synchronous mode, on the client side calls , inside of eglSwapBuffers, when ANativeWindow::queue queueBuffer is called to present the frame from eglSwapBuffers call, SurfaceTextureClient::queue is issued and send it sends the index where of the rendered buffer is to the server side SurfaceTexture::queue. Which cause This causes the index to be queued into SurfaceTexture::mQueue for rendering. SurfaceTexture::mQueue is a wait queue for frame frames that wants want to be rendered. In sync synchronous mode, all the frame frames are showed shown one after another, but whereas in asynchronous mode frames may be dropped in async mode.

For Let us now explain how SurfaceFlinger, after each (the Android compositor) uses this system to get images onto the screen. Each time SurfaceTexture::queue are issuedqueueBuffer is called, it will causes SurfaceFlinger to start for the next renderloopiteration of the render loop. In each render loopiteration, SurfaceFlinger calls to SurfaceTexture::updateTexImage to dequeue a frame from SurfaceTexture::mQueue and bind the that GraphicBuffer into a texture, just like we do in GrallocTextureHostOGL::Lock.

As a result, Android The magic part is that SurfaceFlinger does not explicit unlock need to do the GraphicBuffer as B2G did nowequivalent of GrallocTextureHostOGL::Unlock. Since it will lock next In our case, we have a separate OpenGL texture object for each TextureHost, which typically (at least in the case of a ContentHost) represent one buffer each time new buffer comes(so a double-buffered ContentHost has two TextureHost's). And So we have to unbind the GraphicBuffer from the OpenGL texture before we can hand it will use eglCreateSyncKHR/eglClientWaitSyncKHR back to make sure the buffer are content side --- otherwise it would remain locked for read and couldn't be locked for write for content drawing. By contrast, SurfaceFlinger does not locked before need to worry about this because it uses only one OpenGL texture, so that when it returns the binds a new GraphicBuffer into to it for compositing, that automatically unbinds the buffer pool.previous one!