Android isurface postbuffer processing process

1. Create of isurface

For details about create and surfaceflinger of surface, refer to this article:

Http://blog.csdn.net/yili_xie/archive/2009/11/12/4803527.aspx

Android started a lot early, and now I can only step by step follow the footsteps of the revolutionary martyrs.

Each application has an isurface object that is set in, such as cameraservice of camera and Mio of opencore. We only need to know how to use it.

2. app call process.

After reading the code, we can see that this call is very simple.

Initialize memory first

View plain
Copy to clipboard
Print
?

1. Mframeheap =
   New
   Memoryheapbase (framesize * kbuffercount );
   
2. If
   (Mframeheap-> heapid () <0)
   
3. {
4. LogE ("error creating frame buffer Heap"
   );
   
5. Return
    
   False
   ;
   
6. }

Register memory on isurface

View plain
Copy to clipboard
Print
?

1. Isurface: bufferheap buffers (displaywidth, displayheight,
   
2. Displaywidth, displayheight, pixel_format_rgb_565, mframeheap );
3. Msurface-> registerbuffers (buffers );

Call postbuffer.

Msurface-> postbuffer (mframebuffers [mframebufferindex]);

Here we extract the code from android_surface_output.cpp, which is similar to cameraservice.

Here we will focus on the processing of postbuffer.

3. postbuffer processing process. (Default, overlay is not supported in our system)

Two public bpinterface <isurface> classes are implemented in isurface. cpp: bpsurface bnsurface

Bpsurface is a service-side call using a binder.

Bnsurface is the call back from surfaceflinger.

We write msurface-> postbuffer actually calls bpsurface: postbuffer

Its implementation is:

Remote ()-> transact (post_buffer, Data, & reply, ibinder: flag_oneway );

(I am not very clear about the Binder Mechanism.) There is a comment for the binder calling on the developer's website:

The key ibinder API is transact () matched by binder. ontransact ().
These methods allow you to send a call to an ibinder object and receive
Call coming in to a binder object, respectively. This transaction API
Is synchronous, such that a call to transact () does not return until
Target has returned from binder. ontransact (); this is the expected
Behavior when calling an object that exists in the local process, and
The underlying inter-process communication (IPC) mechanic ensures that
These same semantics apply when going processing SS processes.

That is to say, the entire binder call process is synchronized.

Callback to: bnsurface: ontransact

View plain
Copy to clipboard
Print
?

1. Case
   Post_buffer :{
   
2. Check_interface (isurface, Data, reply );
3. Ssize_t offset = data. readint32 ();
4. Postbuffer (offset );
5. Return
   No_error;
   
6. } Break
   ;
   

Postbuffer: layerbuffer: buffersource: postbuffer (ssize_t offset) in layerbuffer is called here)

For the concepts of these layers in surfaceflinger, you can also refer to the blog that has been drunk for thousands of years. I am not very clear yet.

View plain
Copy to clipboard
Print
?

1. If
   (Buffers. heap! = 0 ){
   
2. Buffer = new
   Layerbuffer: buffer (buffers, offset );
   
3. If
   (Buffer-> getstatus ()! = No_error)
   
4. Buffer. Clear ();
5. Setbuffer (buffer );
6. Mlayer. invalidate ();
7. }

 
Here, the setbuffer (buffer); will record the buffer you want to post. Then, call mflinger-> signalevent () through layerbase: invalidate ()

When an event is triggered, it is returned.

Surfaceflinger
This event will be processed in surfaceflinger: threadloop. Eventually
Layerbuffer: buffersource: ondraw function. In layer, the data in the surface is merged.

Back to our call to postbuffer, we can find that this is the processing of two processes. After the client process is called, it only notifies surfaceflinger that I want to display
Surfaceflinger does not know when to process and when to actually use this memory. Therefore, although the binder is synchronous
While buffer is asynchronous. I did a test myself. After postbuffer, I immediately modified the post memory content and finally found that
The content is changed. Postbuffer then sleeps for 40 ms, and the screen will not be spent. This indicates that surfaceflinger has completed this before modifying memory.
The draw of the buffer works.

 

Http://blog.csdn.net/saphy/archive/2010/07/01/5707413.aspx