Changes

The android::GraphicBuffer class is refcounted and the underlying gralloc 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

That's the right way to hold on to a gralloc buffer in a given process. But since gralloc buffers are shared across multiple processes, and GraphicBuffer objects only exist in one process, a different type of object has to be actually shared and reference-counted across processes. That is the notion of a gralloc buffer ''handle'', which is referenced by a file descriptor.

So when a Think of the gralloc buffer is shared between two processesas a file, each process has its own GraphicBuffer object with its own refcount; these are sharing and multiple file descriptors exist that refer to the same underlying gralloc buffer ''handle''file. The sharing Just like what happens by calling GraphicBuffer::flatten to serialize and GraphicBuffer::unflatten with normal files, the kernel keeps track of open file descriptors to deserialize it. GraphicBuffer::unflatten will call mBufferMapper.registerBuffer To transfer a gralloc buffer across processes, you send a file descriptor over a socket using standard kernel functionality to ensure that the underlying buffer handle is refcounted correctlydo so.

So when a gralloc buffer is shared between two processes, each process has its own GraphicBuffer object with its own refcount; these are sharing the same underlying gralloc buffer (but have different filed descriptors opened for it). The sharing happens by calling GraphicBuffer::flatten to serialize and GraphicBuffer::unflatten to deserialize it. GraphicBuffer::unflatten will call mBufferMapper.registerBuffer to ensure that the underlying buffer handle is refcounted correctly. When a GraphicBuffer's refcount goes to zero, the destructor will call free_handle which call mBufferMapper.unregisterBuffer, which will decrement close the file descriptor, thus decrementing the refcount of the gralloc buffer ''handle''.

The usage flag is some kind of a hint for performance optimization. When you use SW flags, it may just disable all possible optimizations there. Since CPU usually cache data into registers, when we want to lock the buffer for read/write, it have to maintain the cache for correct data. However, other hardware that can use GraphicBuffer on Android e.g. Codec, Camera, GPU do not cache data. It locks/unlocks the buffer in a faster fashion.

It may definitely helps on perforamce performance if we can use the usage flag correctly to describe our purpose about the buffer. In particular, if the SW_READ/SW_WRITE usage flags are set, the GL driver and others will make sure to flush the cache after any rendering operation so that the memory is ready for software reading or writing. Only specify the flags that you need.