The relationship between 1.1.1 application and Bufferqueue
Then continue to explain the unresolved issues in the previous section.
Now that we understand the general process by which an application uses Surfaceflinger to draw work, it is only in the process that the bufferqueue is present until the end. How does the application specifically use Bufferqueue to get the job done?
It is easy to observe that when the application side initiates a request to create a surface through Isurfacecomposerclient::createsurface (), the Surfaceflinger service process creates a layer on this side. Since layer represents a picture layer, it definitely needs to have a place to store the layer data, so we choose to do it from here as a portal.
/*frameworks/native/services/surfaceflinger/surfaceflinger.cpp*/
/* The application is first to access the Createsurface through Isurfacecomposerclient, which is actually just an intermediary that transmits the application request to the Surfaceflinger message queue. Instead of directly calling Surfaceflinger to handle it. This is necessary because there are a lot of messages from each application that need to be processed by Surfaceflinger in a system, except in case of emergency, you should wait in line.
Sp<isurface>surfaceflinger::createsurface (isurfacecomposerclient::surface_data_t* params,
conststring8& name, const sp<client>& Client, Displayid D,
UINT32_TW, uint32_t H, pixelformat format, uint32_t flags)
{
sp<layerbaseclient>layer;
sp<isurface>surfacehandle;
...
sp<layer>normallayer;
Switch (Flags &efxsurfacemask) {//layer type
Case Efxsurfacenormal:
Normallayer = Createnormalsurface (client, D, W, h, flags, format);
Layer =normallayer;
Break
Case efxsurfaceblur://4.1 system blur and Dim type as a
Case Efxsurfacedim:
Layer = Createdimsurface (client, D, W, h, flags);
Break
Case Efxsurfacescreenshot:
Layer = Createscreenshotsurface (client, D, W, h, flags);
Break
}
if (layer!= 0) {...
Surfacehandle = Layer->getsurface ();
...
}
return surfacehandle;
}