From View To Pixel
Creating a great UI experience is a main goal for us as developers. In order to do so, first step is to understand how does the system work, so we can better coordinate with it, benefit from its advantages, and avoid its flaws.
I recently gave a talk about Layout Performance, and decided to post some of my talk notes in a short posts series.
Basic thing to understand about our UI is — how is it created?
How does the high level object we write, such as new Button(), on java code, or xml become pixels on screen?
It basically goes like this:
The CPU takes the high level object and turns it into a display list — a set of commands for drawing it.
GPU (Graphics Processing Unit) is a hardware piece which masters at Rasterization.
Rasterization- taking high level object (button, string, etc…) and turning it into pixels in a texture or on the screen.
The commands created on the CPU are uploaded to the GPU with OpenGL-ES api, in the format the latter can use for rasterizing.
Once uploaded, the display list object is cached. That way, should we want to draw the display list again, there’s no need in creating it, but just redrawing the existing one- which is much cheaper.
This process, unsurprisingly, might be time consuming.
Creating the display list for an object
Uploading to the GPU is expensive.
Therefore, we should strive to reduce the number of time these actions are performed.
An example for optimization the system does for us, is in handling resources provided by our theme, like bitmaps and drawables. The system groups them into one texture anduploads it to the GPU which, as noted above, caches them.
That way, it is really cheap for us to use those, as they are being drawn from cache without the need to be converted or upload to GPU.
Hopefully it is clearer now how does a view turns into pixels on our Android device screen.