Understanding the hidden cost of transparency on Android

Question

I'm watching the video https://youtu.be/wIy8g8yNhNk

My first question.

As far as I understand from the video, when we draw a View that is opaque, we just put data, roughly speaking, a bitmap to the screen. That's called rendering. Is that right?

My second question.

Now let's draw a TextView with an opaque background an a semi-transparent text. Why should it be a two-step process as described in the video: we draw the TexView opaque and then apply a new alpha value to make text semi-transparent? Is it just the way Android was designed? Why can't we draw a semi-transparent pixel in one step?

My third question.

Here Ian Ne-Lewis's telling us about a view with two parts: opaque (on top) and semi-transparent (below the opaque part). He says the two parts don't overlap. But the opaque part is on top of the semi-transparent part. So why does he say these views don't overlap? As far as I understand, by "overlapping" he means having something semi-transparent on top of something opaque.

Answer 1

Answering your first question:

Rendering is the process executed by the Android Framework when it is drawing your opaque View on the screen.

Second Question

To render that TextView, Android will first draw the opaque background and then the semi-transparent Text. And as you saw on the video: When rendering alpha layers, android has to redraw the background layers to see what color should the alpha blend to.

That's just the way Android was designed. Even if both the background and the text were opaque, Android would first draw the background and then the text (but this time it doesn't need to check the background to blend).

Third Question

I think you didn't understand correctly the meaning of overlapping. Here's an example: