One of the many novelties and improvements of the overall user experience brought forth by Android 4.0 Ice Cream Sandwich is the increased use of GPU acceleration in rendering the basic UI elements of the system. We deliberately say “increased” because previous Android versions also used the graphics subsystem to render certain parts of the UI, contrary to popular belief, but to a much lesser extent than is currently the case.
A large number of mobile devices running on this operating system, especially those from the higher class, have a separate graphics subsystem besides the central processing unit. However, the Android OS was designed in such a way that it relied little, if at all, on the said subsystem when rendering windows, menus and all other standard UI elements. Of course, the presence of a GPU was invaluable for other applications, particularly games.
All applications developed and certified for Android 4.0 and upwards will automatically carry optimisations for GPU rendering, unlike the previous practice, where this sort of thing had to be explicitly stated during development. Full hardware acceleration has been around since Android 3.0, by setting a flag inside the app that approves hardware acceleration, when all element-rendering is transferred to the GPU. The only difference in Android’s 4.0 iteration is that appropriate commands don’t need to be explicitly inserted into the manifest file (android:hardwareAccelerated=true), as this will be enabled by default. The advantages of this approach are more than clear, as the specifically developed GPU will tackle all tasks it was made for in the first place, leaving the CPU free of this sort of operations and providing more raw power for all the other computing, leading to an overall increase in performance and execution rate. This is mostly noticeable in the smoother interaction with the graphic elements of the UI, especially in scenarios such as scrolling long text or content-rich webpages.
However, is everything as perfect as Google would have us believe? The main problem is that GPU acceleration is rather taxing memory-wise, a lot more compared to software rendering. This is why devices such as Samsung’s Nexus S and Google’s Galaxy Nexus model will see the very utilisation of OpenGL inside a hardware-rendering process costing as much as 8 MB RAM! This quantity of RAM has to be taken from somewhere, mostly from background processes which are otherwise left “awake”, which in turn causes a slower transfer from one app to the other. Needless to say, older devices with less RAM are going to be hit even harder. This is why hardware acceleration was turned back off for certain UI elements in several models, such as Galaxy S, for instance, simply because this sort of adjustment (or compromise) was needed to keep the previously established user experience. Furthermore, much of the performance numbers will now depend directly on the power of the GPU, regardless of the CPU.
Increasing screen resolution equivalently increases the load on the GPU, as it gets harder and harder to maintain a steady 60 fps when rendering all the UI elements, as much more depends on the GPU than the CPU. However, as the number of pixels grows, GPU generally manages the load much better than the CPU ever could, simply because it was made with this sort of operations in mind, making it optimised for the load it takes upon itself. Another plus for GPU acceleration is a quintessentially important feature of mobile devices – energy efficiency. The GPU is likely to execute all its tasks with consumption far lower than that produced by a CPU.
The direction in which things are moving is clear, and the same goes for expectations from the upcoming revisions of the Android OS, especially in terms of the graphics subsystem. Full hardware rendering is a major milestone that’s virtually all but achieved, and we’re looking forward to its even more efficient implementations in the near future.
