Confirm
157
edits
Changes
→How Gralloc buffers are created and refcounted (non Mozilla-specific)
== How Gralloc buffers are created and refcounted (non Mozilla-specific) ==
The android::GraphicBuffer class is refcountedand the undering buffer handle is refcounted, too. It is meant to be used with Android Strong Pointers (android::sp). That's why you'll see a lot of
android::sp<android::GraphicBuffer>.
That's in fact the right way (the only way) to hold on to a GraphicBuffer.
Since sp object is allocated on stack of each process that share it. The undering buffer handle must be refcounted otherwise the refcount goes wrong when it shared across process. The trick is when GraphicBuffer going shared by processes, the IPC code of Android will call GraphicBuffer::flatten to serialize the GraphicBuffer object, and call GraphicBuffer::unflatten to deserialize it. And GraphicBuffer::unflatten will call mBufferMapper.registerBuffer to make sure the undering buffer handle is refcounted correctly.
And when GraphicBuffer refcount goes to zero, GraphicBuffer::~GraphicBuffer will incurred, and it will call free_handle which call mBufferMapper.unregisterBuffer. So the undering buffer will not released untill all the GraphicBuffer got released and the undering buffer handle refcount goes to zero.
The GraphicBuffer constructors take a "usage" bitfield. We should always pass HW_TEXTURE there, as we always want to use gralloc buffers as the backing surface of OpenGL textures. We also want to pass the right SW_READ_ and SW_WRITE_ flags.
