Hardware Acceleration on Android 4.0

September 13, 2012 by Munir 3 Comments

Hardware acceleration carries out all drawing operations to draw 2D UI elements on a view’s canvas using GPU. 2D rendering pipeline is used to support this hardware acceleration. For instance, menus popping up, dialog boxes, sliding down the notification bar, and transitioning between activities are hardware accelerated.
Android 4.0(API 14 and higher APIs) supports “full” hardware acceleration. All UI elements in windows, and third-party apps will have access to the GPU for rendering. Android 3.0(API 11) had the same system, but now developers will be able to specifically target Android 4.0 with hardware acceleration. Unlike window compositing, drawing inside of a window has traditionally been accomplished by the CPU in Android 2.x and below. In Android 3.0 Honeycomb, however, these functions could be offloaded to the device’s GPU as long as android:hardwareAccelerated=”true” was placed in the application’s manifest.
If an application uses only standard views and Drawables then we can use Hardware Acceleration with no headache. But hardware acceleration may not suitable for some custom views or custom drawing calls. It may cause problems like invisible elements, exceptions, or wrongly rendered pixels.

Controlling Hardware Acceleration
We can control the hardware acceleration from different levels –
 Application
 Activity
 Window
 View
Application Level
Defines that all the views in the application will be rendered using Hardware acceleration. To do this we have to mention a line in the application’s manifest file –

<application android:hardwareAcclerated = “true” >

Activity Level
If hardware acceleration causes problem to render an activity then we can add in the manifest. The following example enables hardware acceleration for the entire application but disable it for an activity.


<application android:hardwareAcclerated = “true” >

…… …..       …..                ……                …..   ….

<activity android:hardwareAcclerated = “false” >

------------------------------------------------ -----------------

</activity>

</application >

Window Level
It creates more fine ViewGroup and window-

 getWindow().setFlags(WindowManager.LayOutParams.FLAG_HARDWARE_ACCLERATED,
 WindowManager.LayOutParams.FLAG_HARDWARE_ACCLERATED);

View Level
You can disable hardware acceleration of an individual view with this code –

 myView.setLayerType(View.LAYER_TYPE_SOFTWARE,null);

Determining a Hardware Accelerated View
To determine a view whether it is hardware accelerated or not specially for the custom views there are 2 ways to check it –
 View.isHardwareAccelerated() returns true if the View is attached to a hardware accelerated window.
 Canvas.isHardwareAccelerated() returns true if the Canvas is hardware accelerated.
If you must do this check in your drawing code, use Canvas.isHardwareAccelerated() instead of View.isHardwareAccelerated() when possible. When a view is attached to a hardware accelerated window, it can still be drawn using a non-hardware accelerated Canvas. This happens, for instance, when drawing a view into a bitmap for caching purposes.

Tips & Tricks for drawing better views
The goal of hardware rendering for the interface is to get smoother operation. Switching to hardware accelerated 2D graphics can instantly increase performance, but you should still design your application to use the GPU effectively by following these recommendations:

Reduce the number of views in your application
The more views the system has to draw, the slower it will be. This applies to the software rendering pipeline as well. Reducing views is one of the easiest ways to optimize your UI.
Avoid overdraw
Do not draw too many layers on top of each other. Remove any views that are completely obscured by other opaque views on top of it. If you need to draw several layers blended on top of each other, consider merging them into a single layer. A good rule of thumb with current hardware is to not draw more than 2.5 times the number of pixels on screen per frame (transparent pixels in a bitmap count!).
Don’t create render objects in draw methods
A common mistake is to create a new Paint or a new Path every time a rendering method is invoked. This forces the garbage collector to run more often and also bypasses caches and optimizations in the hardware pipeline.
Don’t modify shapes too often
Complex shapes, paths, and circles for instance, are rendered using texture masks. Every time you create or modify a path, the hardware pipeline creates a new mask, which can be expensive.
Don’t modify bitmaps too often
Every time you change the content of a bitmap, it is uploaded again as a GPU texture the next time you draw it.
Use alpha with care
When you make a view translucent using setAlpha(), AlphaAnimation, or ObjectAnimator, it is rendered in an off-screen buffer which doubles the required fill-rate. When applying alpha on very large views, consider setting the view’s layer type to LAYER_TYPE_HARDWARE.