7.5 Android Hardware Acceleration

The android 2D rendering pipeline supports hardware acceleration. Now you might be wondering what is this pipelining. Well pipelining is actually an implementation technique. Multiple instructions are executed. So how is this useful in android? Well, the answer is we have multiple drawing operations which are performed over a view. With pipelining this multiple executions are possible. Now because of multiple operations, multiple resources are engaged to accomplish these operations. Thus application will create a bottleneck effect on usage of RAM.

By default if we use android API level 14 or API level above 14 then this is automatically enabled. Hardware acceleration is not a very good friend of 2D operations. Although it doesn’t pose any problems but it may affect custom views or some standard view’s performance. But android is smart enough to tackle this sort of problem. We can explicitly enable or disable hardware acceleration. Hardware acceleration can be controlled at following levels:

Application Level: In application tag <application/>, hardware acceleration can be enabled. At application level the acceleration ability is enabled for entire application.

Activity level: At activity level, it might be enable or disabled. In other words, if acceleration is turned on globally at application level but you don’t want an activity in particular to be accelerated then it is possible to do that. <activity /> tag is used for this purpose. Don’t worry I will such an example manifest file.

Window Level: At window level, we can enable or disable hardware acceleration at window level. This has to be coded inside the activity.

View Level: We can control the hardware acceleration at view level in the runtime i.e. each view can be customized as far as hardware acceleration is concerned. Again it is coded inside activity at view level. View object is used to enable or disable the feature by using flags. We will have a sample activity for demonstration.

7.5.2 Android Drawing Models

Android has two drawing models and they are:

Software-based model.

Hardware-based model.

In software model, whenever application is updated it calls the invalidate() method which spread out the message about the redrawing of view in the view hierarchy. But the two major concerns about this model are:

Drawing model may hide bugs in the application.

For every pass of draw extensive coding is involved.

In case of hardware acceleration, although the basic logic is same but working strategy is different. The drawing commands are not immediately executed. They are recorded in a display list. Only those views are recorded and updated which are reported by invalidate() method as dirty views. So it is a sort of drawing optimization.

7.5.3 Influential Factors

There are many factors which influence the usage criteria of software or hardware based rendering at view level. Among them the following are the most competent factors:

Visual effects: Hardware or software layer type is used. Additionally a paint method is applied for visual treatments to a view.

Compatibility: software layer type is used. The view forcefully rendered in software. It is a very competent option when the hardware pipelining causes trouble in rendering.

Performance: Hardware layer is used to render view into hardware texture.

While using Android hardware acceleration, following points should be kept in mind:

Number of views in application should be adequate. They should be minimum or optimal in number.

Overdrawing should be avoided.

Render objects should not be created in draw methods.

Shapes should not be modified often.

Bitmaps modification should be least or avoided.

Alpha should be used with care.

Next section would deal with multimedia framework. Hope this tutorial was useful for you. See you in the next section. Till then keep practicing. Happy App Developing!!!