Android GUI system Surfaceflinger (3)

Local windows in Android Framebuffernativewindow

1.1 The local windows in Android

In the learning process of OpenGL, we keep mentioning the concept of "local window" (NativeWindow). So how does the Android system localize OpenGL ES, or does it provide a local window?

Based on the GUI design concept of the entire Android system, it's not hard to guess that at least two local windows are needed:

Facing managers (Surfaceflinger)

Since Surfaceflinger acts as the manager of all UI interfaces in the system, it is understandable that it needs to hold "local windows" directly or indirectly. In the previous section, we already know that this window is Framebuffernativewindow.

Application-oriented

Let's give the answer first, this kind of window is surfacetextureclient

Many readers may feel puzzled, why need two kinds of windows, the same system should not have only one window? Like this:

Figure 11?4 Ideal Window System

In this diagram, Windows manages framebuffer. For example, OpenGL is like a general-purpose printer, and as long as the correct instructions are entered, it can output the results as required, while window is "paper", which is used to host the output of OpenGL. OpenGL doesn't mind that window is A4 paper or A6, or even plastic, it's just "local window".

Having understood this diagram, let's think about whether such a model meets the requirements of Android. If the entire system has only one program that needs to display the UI, we have reason to believe that it is competent. But what if there are N UI programs? Framebuffer clearly has only one, and it is impossible for individual applications to manage themselves separately.

This is the problem, how to improve it? What's the following method?

Figure 11?5 Improved Window System