OpenGL ES Local Window surfacetextureclient
1.1.1 Surfacetextureclient
The local window for the application side is surfacetextureclient, and like Framebuffernativewindow, it must inherit Anativewindow:
Class Surfacetextureclient
: Publicanativeobjectbase<anativewindow, surfacetextureclient,refbase>
This local window of course also needs to implement the "Protocol" Anativewindow, and our focus is on how it differs from the previous framebuffernativewindow. The Surfacetextureclient constructor simply invokes the Init function, which assigns an initial value to the Anativewindow::d equeuebuffer, and other function pointers and internal variables. Since the function of the entire function is simple, we only extract a subset of them:
/*frameworks/native/libs/gui/surfacetextureclient.cpp*/
void Surfacetextureclient::init () {
/* Give the function pointer in the Anativewindow to the value * *
Anativewindow::setswapinterval =hook_setswapinterval;
Anativewindow::d equeuebuffer = Hook_dequeuebuffer;
...
/* To assign values to internal variables, because at this point the user has not really launched the application, so the basic is 0*/
mreqwidth = 0;
mreqheight = 0;
...
mdefaultwidth = 0;
mdefaultheight = 0;
muserwidth = 0;
muserheight = 0;..
}
Surfacetextureclient is intended for all UI applications in the Android system, which means that it takes on the UI display requirements in a single application process. Based on this consideration, it can be inferred that its internal implementation will at least have the following points:
"Artboards" provided to the upper level (primarily the Java layer) for drawing images
As I said before, the memory allocated by this local window should not come from the frame buffer, so who is to assign it and how to manage it?
What is the division between it and Surfaceflinger?
Obviously Surfaceflinger needs to collect image data drawn by all applications in the system and then focus on the physical screen. What role did surfacetextureclient play in the process?