1page.title=Graphics architecture 2@jd:body 3 4<!-- 5 Copyright 2014 The Android Open Source Project 6 7 Licensed under the Apache License, Version 2.0 (the "License"); 8 you may not use this file except in compliance with the License. 9 You may obtain a copy of the License at 10 11 http://www.apache.org/licenses/LICENSE-2.0 12 13 Unless required by applicable law or agreed to in writing, software 14 distributed under the License is distributed on an "AS IS" BASIS, 15 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 16 See the License for the specific language governing permissions and 17 limitations under the License. 18--> 19<div id="qv-wrapper"> 20 <div id="qv"> 21 <h2>In this document</h2> 22 <ol id="auto-toc"> 23 </ol> 24 </div> 25</div> 26 27 28<p><em>What every developer should know about Surface, SurfaceHolder, 29EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView, 30SurfaceFlinger, and Vulkan.</em></p> 31 32<p>This page describes essential elements of the Android system-level graphics 33architecture and how they are used by the application framework and multimedia 34system. The focus is on how buffers of graphical data move through the system. 35If you've ever wondered why SurfaceView and TextureView behave the way they do, 36or how Surface and EGLSurface interact, you are in the correct place.</p> 37 38<p>Some familiarity with Android devices and application development is assumed. 39You don't need detailed knowledge of the app framework and very few API calls 40are mentioned, but the material doesn't overlap with other public 41documentation. The goal is to provide details on the significant events 42involved in rendering a frame for output to help you make informed choices 43when designing an application. To achieve this, we work from the bottom up, 44describing how the UI classes work rather than how they can be used.</p> 45 46<p>This section includes several pages covering everything from background 47material to HAL details to use cases. It starts with an explanation of Android 48graphics buffers, describes the composition and display mechanism, then proceeds 49to the higher-level mechanisms that supply the compositor with data. We 50recommend reading pages in the order listed below rather than skipping to a 51topic that sounds interesting.</p> 52 53<h2 id=low_level>Low-level components</h2> 54 55<ul> 56<li><a href="{@docRoot}devices/graphics/arch-bq-gralloc.html">BufferQueue and 57gralloc</a>. BufferQueue connects something that generates buffers of graphical 58data (the <em>producer</em>) to something that accepts the data for display or 59further processing (the <em>consumer</em>). Buffer allocations are performed 60through the <em>gralloc</em> memory allocator implemented through a 61vendor-specific HAL interface.</li> 62 63<li><a href="{@docRoot}devices/graphics/arch-sf-hwc.html">SurfaceFlinger, 64Hardware Composer, and virtual displays</a>. SurfaceFlinger accepts buffers of 65data from multiple sources, composites them, and sends them to the display. The 66Hardware Composer HAL (HWC) determines the most efficient way to composite 67buffers with the available hardware, and virtual displays make composited output 68available within the system (recording the screen or sending the screen over a 69network).</li> 70 71<li><a href="{@docRoot}devices/graphics/arch-sh.html">Surface, Canvas, and 72SurfaceHolder</a>. A Surface produces a buffer queue that is often consumed by 73SurfaceFlinger. When rendering onto a Surface, the result ends up in a buffer 74that gets shipped to the consumer. Canvas APIs provide a software implementation 75(with hardware-acceleration support) for drawing directly on a Surface 76(low-level alternative to OpenGL ES). Anything having to do with a View involves 77a SurfaceHolder, whose APIs enable getting and setting Surface parameters such 78as size and format.</li> 79 80<li><a href="{@docRoot}devices/graphics/arch-egl-opengl.html">EGLSurface and 81OpenGL ES</a>. OpenGL ES (GLES) defines a graphics-rendering API designed to be 82combined with EGL, a library that knows how to create and access windows through 83the operating system (to draw textured polygons, use GLES calls; to put 84rendering on the screen, use EGL calls). This page also covers ANativeWindow, 85the C/C++ equivalent of the Java Surface class used to create an EGL window 86surface from native code.</li> 87 88<li><a href="{@docRoot}devices/graphics/arch-vulkan.html">Vulkan</a>. Vulkan is 89a low-overhead, cross-platform API for high-performance 3D graphics. Like OpenGL 90ES, Vulkan provides tools for creating high-quality, real-time graphics in 91applications. Vulkan advantages include reductions in CPU overhead and support 92for the <a href="https://www.khronos.org/spir">SPIR-V Binary Intermediate</a> 93language.</li> 94 95</ul> 96 97<h2 id=high_level>High-level components</h2> 98 99<ul> 100<li><a href="{@docRoot}devices/graphics/arch-sv-glsv.html">SurfaceView and 101GLSurfaceView</a>. SurfaceView combines a Surface and a View. SurfaceView's View 102components are composited by SurfaceFlinger (and not the app), enabling 103rendering from a separate thread/process and isolation from app UI rendering. 104GLSurfaceView provides helper classes to manage EGL contexts, inter-thread 105communication, and interaction with the Activity lifecycle (but is not required 106to use GLES).</li> 107 108<li><a href="{@docRoot}devices/graphics/arch-st.html">SurfaceTexture</a>. 109SurfaceTexture combines a Surface and GLES texture to create a BufferQueue for 110which your app is the consumer. When a producer queues a new buffer, it notifies 111your app, which in turn releases the previously-held buffer, acquires the new 112buffer from the queue, and makes EGL calls to make the buffer available to GLES 113as an external texture. Android 7.0 adds support for secure texture video 114playback enabling GPU post-processing of protected video content.</li> 115 116<li><a href="{@docRoot}devices/graphics/arch-tv.html">TextureView</a>. 117TextureView combines a View with a SurfaceTexture. TextureView wraps a 118SurfaceTexture and takes responsibility for responding to callbacks and 119acquiring new buffers. When drawing, TextureView uses the contents of the most 120recently received buffer as its data source, rendering wherever and however the 121View state indicates it should. View composition is always performed with GLES, 122meaning updates to contents may cause other View elements to redraw as well.</li> 123</ul> 124