Android 4.1 Surface system change description

Source: Internet
Author: User
Time is really clever. I didn't plan to write the Surface system (the difficulty after Surface change is really rough compared to AudioFlinger), but to celebrate the second masterpiece of yanze Luola, I decided to stick to it. Next we will continue the analysis style of Audio and introduce the changes to the Surface system from several aspects (JB claims to have done a lot of quality improvements on the Surface, it is nothing more than introducing VSYNC, Triple Buffering, which is already familiar on the PC. But JB, can you make sure this mechanism runs on a single-core machine? Win Phone Single-core, smoother than multi-core Android machines. I'm afraid there is still a problem with the Display architecture on the upper layer of Android, right ??!) Like Audio, if you really want to understand how the Surface system works, you 'd better understand its evolution history. In Chapter 8th of "deep understanding of Android volume I", the Surface system of 2.2 has been downloaded from top to bottom. So all day long, we are clamoring for the possibility of mosaic in a large film. Do you want to figure out the mosaic produced in the book because you don't understand it ?? 1. Surface WorkflowLet's first talk about the Surface workflow (only on the Native layer ):
  • The creation of the Java layer Surface will result in calling of the Surface_init function of JNI. This Surface is not the Surface used by the APP. It will go through the migration process. Please refer to the books mentioned above and write them in great detail.
  • Surface_writeToParcel: transmits the Surface to the process where the APP is located for use.
  • The process of the APP restores a Surface object through Surface_readFromParcel. Now, your APP has a face.
  • The APP calls Surface_lockCanvas to obtain a canvas, and the APP then draws a painting on the canvas.
  • The APP calls Surface_unlockCanvasAndPost to push the data to SurfaceFlinger and complete the painting.
The above process has not changed in JB. From 2.2 to 4.1. There are basically no changes in this process. You can simply take a look at it. 2. SurfaceFlinger change description 3.1 SF member change descriptionSF has changed a lot, mainly because its brothers have changed a lot. Let's take a look at figure 1.

Figure 1 DisplayHardware and sibling Diagram 1 are described as follows:
  • JB modified DisplayHardware and HardwareComposer in order to support VSYNC (don't understand students, refer to this article http://blog.sina.com.cn/s/blog_4a3946360100wjoo.html) (this ghost class actually appears 3.0 ,). In short, VSYNC is a synchronization event. Synchronization is all at this point. You can check the status. It's like some American film agents who always shake their watches before doing something, just like the next time. As for what to do after the synchronization event is obtained, you will be able to see the code later.
  • In principle, VSYNC provides a display chip (hereinafter referred to as a video card. However, JB went too fast. Many hardware devices were not supported, or interfaces were not supported. Therefore, it is not guaranteed that each JB mobile phone has a VSYNC event from the hardware. Why? At last, JB has a VSyncThread, which is a thread used for timed callback to simulate the hardware VSYNC event (this time must be accurate, so the thread priority must be relatively high ). See, this is another evidence, indicating that JB is not suitable for running on a single core CPU (I think dual core may not be suitable ).
  • To support hardware VSYNC events, the corresponding interfaces are also added to HardwareComposer.
  • DisplayHardware is derived from the internal class EventHandler of DisplayHardwareBase and HardwareComposer. Derived from EventHandler is nothing more than the onVsyncReceived function based on it. This function will be called at the VSYNC event.
  • Because of the encapsulation of layers (just like the package of domestic engineering layers), DisplayHardware defines a VsyncHandler virtual class, hoping that people will inherit its onVsyncReceived function. Since DH is used for SF, You can boldly guess that this onVsyncReceived will be handled by the SF layer. If you look at the code, you will find that the onVsyncReceived function implemented by DisplayHardware is actually meaningless, that is, to call an onvsynchandler function that implements the VsyncHandler object. (A bit of Tongue Twister? Take a closer look !)
See figure 2 again:

Figure 2 SF and Its sibling Figure 2 are explained as follows:
  • First look at the top left. Yes, you are not mistaken. MessageHandler, logoff, and MessageBase are also available here. This was previously only a Java layer (so the principle is the same, and the language is just a tool. If you understand the Message-related knowledge of the Java layer, why can't you understand it? Unless you don't really understand the Java-layer Message stuff, refer to this blog http://blog.csdn.net/innost/article/details/6055793 ). Note that MessageBase is a virtual class. On the one hand, it implements the handleMessage function of the parent class, and on the other hand, it requires sub-classes to implement the handle function. This is different from the Message at the Java layer. Therefore, when you find a place in SF to throw a message to MessageQueue, don't look for Handler. Let's look at the handle function of the message first!
  • SF saves a MessageQueue object and acts as the display server. It also uses the Message Queue method to drive its own work. This method has already been done in 4.0, but it is not complete enough. In JB, The threadLoop function of SF has one sentence: waitForEvent (). For this change, I can only say: very good, very powerful!
  • SF saves an EventThread object, which is a thread class. It is derived from VsyncHandler and implements the onVsyncReceived function.
  • SF adds the IDisplayEventConnection cross-binder interface. The data channel is BitTube (MD, Tube means pipe. Speechless. People who develop SF and those who develop AF sit far away ..). This class is used to collect underlying VSYNC events and distribute them to various connections. Boldly guess if some apps require different FPS, so DisplayHardware first needs to provide a minimum unit of VSYNC time, and then EventThread will trigger it based on the VSYNC time applied by the application. Similar to clock frequency division!
Bold guesses, careful proof. Well, I hope you can master this method. 3.2 description of createSurface changesFrom the process point of view, this function has not changed, and the changes are still those brothers. See Figure 3. Here we will only discuss the NormalSurface situation:

Figure 3 Relationship Between Layer and SurfaceTexture:
  • Figure 3 the three on the left are derived links of layers. What is Layer? Layer is something in SF that represents each display Layer. It processes many logics such as painting.
  • ISurfaceTexture on the right. It is actually an interface of the Android Native display layer, and its functions are similar to AudioTrack and AudioRecord. In the future, an example will be provided, that is, painting using the ISurfaceTexture API directly. Compared with other versions, JB abstracts the BufferQueue layer in SurfaceTexure. I personally think it is more complicated. BufferQueue. It may be helpful when processing PageFlip.
  • When the client calls getSurfaceTexture, SurfaceTextureLayer is returned to the client in createSurface of the Layer. The client then calls requestBuffer, queueBuffer, and dequeueBuffer to obtain GraphicBuffer (simply think it is a video memory ).
  • ISurfaceTexture internally defines two POD structs, QueueBufferInput/Output, and POD struct, which are actually a struct with no static members. The two struct structures contain information such as width, height, and timestamp, which are passed as parameters of the queueBuffer function. The specific function is not detailed.
It's nothing more complicated than learning the relevant design documents. 3.3 dequeueBuffer and queueBuffer change description
  • DequeueBuffer: gets the memory of the idle video card to paint the app. If TARGET_DISABLE_TRIPLE_BUFFERING is enabled during compilation, the default graphics card memory size is 2; otherwise, it is 3. Code related to the queue/dequeue operation, as early as 2.2, it does not support only two pieces. In other words, the code can support 3, 4, 5, and so on. Isn't it just an array? Of course it's not stupid to write 2! This part of logic is not much changed compared with ICS. I just moved the code to BufferQueue.
The following figure shows figure 4, the flowchart of the queueBuffer function. This part has changed a lot.

Figure 4 the whole complicated process of queueBuffer is actually a simple callback from step 1. This is the negative effect of too many layers. According to Figure 1, the final call is the requestNextSync of EventThread. This function is very simple and triggers a synchronous broadcast object ..... there are still many knowledge points, but they cannot be put in this section. Next, let's look at the relationship between SurfaceFlinger and EventThread. 3.4 SurfaceFlinger and EventThread workflow descriptionWhat I couldn't explain in the previous section is what EventThread is doing. It and SF are two threads respectively (MD and multi-thread programming. synchronization is very important !) In the readyToRun function of SF, the relationship between SF and ET will be established through the setEventThread function of MesssageQueue. Let's take a look at the code: void MessageQueue: setEventThread (const sp <EventThread> & eventThread) {mEventThread = eventThread; mEvents = eventThread-> createEventConnection (); mEventTube = mEvents-> getDataChannel (); mLooper-> addFd (mEventTube-> getFd (), 0, ALOOPER_EVENT_INPUT, MessageQueue: cb_eventReceiver, this);} That is, when EventThread has something to worry about, it will call back to the SF thread through cb_eventReceiver. Note: Before JB, Android always liked to use pipe for inter-process communication. Now it is changed to socketpair. This is a big change. Therefore, you can have a good time with network programming. It doesn't matter if you don't want to masturbate. It's all about using sockets as pipe. It's all about IPC communication. What do you know about it! After requestSync of EventThread is called, The EventThread thread will send a message to the thread where SF is located through Connection, that is, the cb_eventReceiver was called just now. Figure 4 shows the subsequent workflow. (The SF system has become a tough job now, and you don't know POSIX programming skills. You have to study it in any way .)

Figure 5 SF workflow Step 5 at the end of Step 10 and 11 finally saw the familiar handlePageFlip. FT. Compared with the ICS version, the more functions are tuned, and the more complex the layers are. Don't make it the same as Java Framework at that time, so the efficiency will be ..... Iv. SummaryCompared with AF, SF mainly increases layers and function calls are bypassed. In addition, the IDisplayEventConnection interface is added, which remains to be studied in the future. These things can help you understand jb sf.
Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.