SurfaceFlinger: Share ownership of layers between State and Handle.
Currently the only strong reference to a Layer is held by their parent or the containing layer stack. Firstly, it means that we can not create a SurfaceControl with a null parent. For example, a media decoding library may wish to offer an unparented SurfaceControl representing the decoding Surface, and allow the consumer to parent it between various SurfaceControls as they wish. Secondly it requires lifetime coordination between various levels of the hierarchy, when adding a child you have to be careful to observe the lifetime of the parent because your BufferQueue may become suddenly abandoned at any point. In this change we switch to a reference counted model, such that the Layer remains valid as long as there is a handle to it. We also end the behavior of passing on BufferQueue abandon to children. Layers are only abandoned/disposed when an explicit call to remove is made, or the last reference is dropped. In this CL we switch the handle to holding a strong pointer. We have the handle and the current state forward their references to the main thread to be dropped. We move the contents of onRemoved to the destructor to ensure they are dropped when the last reference is dropped. A second CL will replace the concept of "onRemovedFromCurrentState" with the concept of parent=null, and remove the explicit destroy method, replacing it with an IPC reparent to null. Two additional refactorings are required to follow the other changes. First since we moved mNumLayers to ~Layer it will be executed for the fake parent layer created during screenshots but mNumLayers++ (in addClientLayer) will not be incremented. The most straightforward solution is to balance mNumLayers from the c'tor/d'tor. Second since abandon() is virtual calling it from the d'tor is not safe. We move the call to BufferQueueLayer and remove the abstract method entirely. Bug: 62536731 Bug: 111373437 Bug: 111297488 Test: Transaction_test.cpp Change-Id: I3e815eb9cee39f6def1ef459811448698a93f5c8
Loading
Please register or sign in to comment