Skip to main content

Android UI Internal : UI Composition with Hardware Composer (HWC)

We ended last article with the statement that to reduce  power and increase  performance, surfaceFlinger will offload layer composition to display hardware. This is the so called Hardware Composer. How this offloading works and what is the benifit can be illustrated with following diagram.

composition using GLES and hardware composer

In case 1, all the layers are composited using openGL. The composited image goes to display controller and finally the phone screen.

In case 2, layer 1 goes to display controller directly while layer 2 & 3 are composited by openGL; the display hardware will then blend layer 1 and the composition result of layer 2 & 3 and finally output it to phone screen. 

Apparently, to enable case 2 more sophiscated display controller was needed so as to be able to accept two input and to blend them. What's the benefit to make this added complexity pays off? 

In the first case, every time layer 1 updates, openGL composition will be trigged for all three layers even layer 2/3 does not change; However, in the second case, if only layer 1 updates, it will goes directly to display controller and no openGL composition will happen. Keeping the openGL/3D hardware idle as much as possible is THE most important thing to ensure a long batter life which our customer will be happy with. In addition to this power benefit, composition using display controller is usually more performant than using openGL since display controller can do it parallel with dedicated hardware. To sum up, using hardware composer, we have decreased power consumption and increased performance. 

Whether a layer could be composited using hardware composer depend on the hardware capability and layer's attributions. Nowadays, smart phone's display hardwares support at least 2 simultaneous input, or overlay - a more jargon word.  Google suggests phone should at lease support 4 overlays to cover status bar, system bar, application and live wallpaper effectively. Layer attributions are things like color format(RGB or YUV), alpha value and angle (portrait or landscape). Only when there is available overlay and the capability of the overlay match the the layer attribution, this layer will go to hardware composer.  Usually, video playback using SurfaceView always goes to overlay since its performance and power  is an important KPI (Key Performance Index)  each and every phone strive to get it looks good. Full screen game is another case. 

Check out other articles in Android UI Internal series 

Popular posts from this blog

Android Security: An Overview Of Application Sandbox

The Problem : Define a  policy  to control how various  clients  can  access  different  resources . A  solution: Each  resource  has an  owner  and belongs to a  group . Each  client  has an  owner  but can belongs to multiple  groups . Each  resource  has a  mode  stating the  access permissions  allowed for its  owner ,  group  members and others, respectively. In the context of operating system, or Linux specifically, the  resources  can be files, sockets, etc; the  clients  are actually processes; and we have three  access permissions :read, write and execute.

Android Camera2 API Explained

Compared with the old camera API, the Camera2 API introduced in the L is a lot more complex: more than ten classes are involved, calls (almost always) are asynchronized, plus lots of capture controls and meta data that you feel confused about.

Android Security: A walk-through of SELinux

In  DAC , each process has an owner and belong to one or several groups, and each resource will be assigned different access permission for its owner and group members. It is useful and simple. The problem is once a program gain root privileged, it can do anything. It has only three permissions which you can control, which is very coarse. SELinux is to fix that. It is much fine-grained. It has lots of permissions defined for different type of resources. It is based on the principle of default denial. We need to write rules explicitly state what a process, or a type of process (called domain in SELinux), are allowed to do. That means even root processes are contained. A malicious process belongs to no domain actually end up can do nothing at all. This is a great enhancement to the DAC based security module, and hence the name Security-Enhanced Linux, aka SELinux.