The Android framework offers a variety of graphics rendering APIs for 2D and3D that interact with manufacturer implementations of graphics drivers, so itis important to have a good understanding of how those APIs work at a higherlevel. This page introduces the graphics hardware abstraction layer (HAL) uponwhich those drivers are built.
Application developers draw images to the screen in two ways: with Canvas orOpenGL. See System-level graphicsarchitecture for a detailed description of Android graphicscomponents.
android.graphics.Canvasis a 2D graphics API and is the most popular graphics API among developers.Canvas operations draw all the stock and custom android.view.Viewsin Android. In Android, hardware acceleration for Canvas APIs is accomplishedwith a drawing library called OpenGLRenderer that translates Canvas operationsto OpenGL operations so they can execute on the GPU.
Beginning in Android 4.0, hardware-accelerated Canvas is enabled by default.Consequently, a hardware GPU that supports OpenGL ES 2.0 is mandatory forAndroid 4.0 and later devices. See theHardware Acceleration guide for an explanation of how thehardware-accelerated drawing path works and the differences in its behaviorfrom that of the software drawing path.
In addition to Canvas, the other main way that developers render graphics isby using OpenGL ES to directly render to a surface. Android provides OpenGL ESinterfaces in theandroid.openglpackage that developers can use to call into their GL implementations with theSDK or with native APIs provided in the AndroidNDK.
Android implementers can test OpenGL ES functionality using the drawElements Quality Program, also known as deqp.
No matter what rendering API developers use, everything is rendered onto a"surface." The surface represents the producer side of a buffer queue that isoften consumed by SurfaceFlinger. Every window that is created on the Androidplatform is backed by a surface. All of the visible surfaces rendered arecomposited onto the display by SurfaceFlinger.
The following diagram shows how the key components work together:
Figure 1. How surfaces are rendered
The main components are described below:
An image stream producer can be anything that produces graphic buffers forconsumption. Examples include OpenGL ES, Canvas 2D, and mediaserver videodecoders.
The most common consumer of image streams is SurfaceFlinger, the systemservice that consumes the currently visible surfaces and composites them ontothe display using information provided by the Window Manager. SurfaceFlinger isthe only service that can modify the content of the display. SurfaceFlingeruses OpenGL and the Hardware Composer to compose a group of surfaces.
Other OpenGL ES apps can consume image streams as well, such as the cameraapp consuming a camera preview image stream. Non-GL applications can beconsumers too, for example the ImageReader class.
The Android system service that controls a window, which is a container forviews. A window is always backed by a surface. This service overseeslifecycles, input and focus events, screen orientation, transitions,animations, position, transforms, z-order, and many other aspects of a window.The Window Manager sends all of the window metadata to SurfaceFlinger soSurfaceFlinger can use that data to composite surfaces on the display.
The hardware abstraction for the display subsystem. SurfaceFlinger candelegate certain composition work to the Hardware Composer to offload work fromOpenGL and the GPU. SurfaceFlinger acts as just another OpenGL ES client. Sowhen SurfaceFlinger is actively compositing one buffer or two into a third, forinstance, it is using OpenGL ES. This makes compositing lower power than havingthe GPU conduct all computation.
The Hardware Composer HAL conducts the other half of the work. This HAL isthe central point for all Android graphics rendering. Hardware Composer mustsupport events, one of which is VSYNC. Another is hotplug for plug-and-playHDMI support.
See theHardwareComposer HAL section for more information.
The graphics memory allocator is needed to allocate memory that is requestedby image producers. See the Gralloc HAL section for moreinformation.
See the following diagram for a depiction of the Android graphicspipeline:
Figure 2. Graphic data flow throughAndroid
The objects on the left are renderers producing graphics buffers, such asthe home screen, status bar, and system UI. SurfaceFlinger is the compositorand Hardware Composer is the composer.
BufferQueues provide the glue between the Android graphics components. Theseare a pair of queues that mediate the constant cycle of buffers from theproducer to the consumer. Once the producers hand off their buffers,SurfaceFlinger is responsible for compositing everything onto the display.
See the following diagram for the BufferQueue communication process.
Figure 3. BufferQueue communicationprocess
BufferQueue contains the logic that ties image stream producers and imagestream consumers together. Some examples of image producers are the camerapreviews produced by the camera HAL or OpenGL ES games. Some examples of imageconsumers are SurfaceFlinger or another app that displays an OpenGL ES stream,such as the camera app displaying the camera viewfinder.
BufferQueue is a data structure that combines a buffer pool with a queue anduses Binder IPC to pass buffers between processes. The producer interface, orwhat you pass to somebody who wants to generate graphic buffers, isIGraphicBufferProducer (part of SurfaceTexture).BufferQueue is often used to render to a Surface and consume with a GLConsumer, among other tasks.BufferQueue can operate in three different modes:
Synchronous-like mode - BufferQueue by default operates in asynchronous-like mode, in which every buffer that comes in from the producergoes out at the consumer. No buffer is ever discarded in this mode. And if theproducer is too fast and creates buffers faster than they are being drained, itwill block and wait for free buffers.
Non-blocking mode - BufferQueue can also operate in a non-blockingmode where it generates an error rather than waiting for a buffer in thosecases. No buffer is ever discarded in this mode either. This is useful foravoiding potential deadlocks in application software that may not understandthe complex dependencies of the graphics framework.
Discard mode - Finally, BufferQueue may be configured to discardold buffers rather than generate errors or wait. For instance, if conducting GLrendering to a texture view and drawing as quickly as possible, buffers must bedropped.
To conduct most of this work, SurfaceFlinger acts as just another OpenGL ESclient. So when SurfaceFlinger is actively compositing one buffer or two into athird, for instance, it is using OpenGL ES.
The Hardware Composer HAL conducts the other half of the work. This HAL actsas the central point for all Android graphics rendering.
Since Android graphics offer no explicit parallelism, vendors have longimplemented their own implicit synchronization within their own drivers. Thisis no longer required with the Android graphics synchronization framework. Seethe Explicit synchronization sectionfor implementation instructions.
The synchronization framework explicitly describes dependencies betweendifferent asynchronous operations in the system. The framework provides asimple API that lets components signal when buffers are released. It alsoallows synchronization primitives to be passed between drivers from the kernelto userspace and between userspace processes themselves.
For example, an application may queue up work to be carried out in the GPU.The GPU then starts drawing that image. Although the image hasn’t been drawninto memory yet, the buffer pointer can still be passed to the windowcompositor along with a fence that indicates when the GPU work will befinished. The window compositor may then start processing ahead of time andhand off the work to the display controller. In this manner, the CPU work canbe done ahead of time. Once the GPU finishes, the display controller canimmediately display the image.
The synchronization framework also allows implementers to leveragesynchronization resources in their own hardware components. Finally, theframework provides visibility into the graphics pipeline to aid indebugging.
联系客服
