Confirm
157
edits
Changes
→SurfaceTexture
== SurfaceTexture ==
SurfaceTexture is a client-server architecture. The SurfaceTextureClient implements EGLNativeWindow, into which the application renders. When the Android hardware UI The EGLNativeWindow is a glue to make SurfaceTexture can be usedas render surface of EGL, the SurfaceTextureClient is bound into a EGLSurface, and which abstract out some buffer management detail when the application wants use OpenGL to present the buffer, manipulate shared memory in Android and make it calls easier to use OpenGL across process. Since eglSwapBuffers which calls to EGLNativeWindow::queue dequeueBuffer to acquire new buffer and EGLNativeWindow::dequeuequeueBuffer to return the buffer implicitly, the user can avoid to create several textures and manage them directly. The other useful feature of implement it in this way is that most BSP vendor provided graphics profilers(e.g. Adreno profiler from QCOM, PerfHUD ES from nVidia) that recognize the eglSwapBuffers call as frame boundary to collect frame based GL information from driver to help developement and performance tuning. SurfaceTexture is a unified buffer management mechanism on Android, which you can setup it to run in different mode: sync/async, single/multiple buffer by simple function call which make SurfaceTexture be used everywhere in Android: Codec/Camera configure it to 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 of Google Miracast.
SurfaceTexture is the server-side class. SurfaceTextureClient is the client-side class. Both store an array of GraphicBuffers, called mSlots. 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 client side issues a SurfaceTextureClient::dequeueBuffer call to get a new buffer to paint to. If there are not already enough buffers, and the number of buffers is not over the limit (32), it sends an IPC message that results in a call to SurfaceTexture::dequeueBuffer which allocates the GraphicBuffer. And after buffer allocation, the client side will send an IPC message that results in a call to SurfaceTexture::requestBuffer to get the gralloc buffer handle serialized over IPC back to it, and construct a GraphicBuffer around this handle, 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 by index.
