If I'm understanding it right, I think the AHardwareBuffer GpuMemoryBufferHandle will also need updating. It's currently implemented as a SharedMemoryHandle subtype since it's also transported via file descriptor, but it needs custom transport/mapping methods.
(I had initially implemented this as a custom subtype, but we had decided during review to move to the SharedMemoryHandle API for consistency and lifecycle handling.)
See for example:
https://cs.chromium.org/chromium/src/base/memory/shared_memory_handle_android.cc?sq=package:chromium&dr&l=50https://cs.chromium.org/chromium/src/ui/gfx/gpu_memory_buffer.h?type=cs&q=gpumemorybuffer&sq=package:chromium&l=37
Please let me know what the best way is to proceed here. Unfortunately this doesn't have good end-to-end test coverage since AHardwareBuffer only works on Android O, and at the time of implementation that wasn't available on any of the bots.
Calling this done. Mojo implementation is now entirely moved away from SharedMemoryHandle, and there are ample facilities in Mojo public APIs for wrapping and unwrapping the new region types.
There are still quite a few uses of mojo::WrapSharedMemoryHandle and mojo::UnwrapSharedMemoryHandle, but I view these as separate concerns in the overall effort to port code away from SharedMemoryHandle. i.e. it's trivial to convert an UnwrapSharedMemoryHandle invocation to an (e.g.) UnwrapReadOnlySharedMemoryRegion invocation, provided the surrounded code is also ported to use ReadOnlySharedMemoryRegion instead of SharedMemoryHandle.
Comment 1 by roc...@chromium.org
, Mar 27 2018Status: Started (was: Assigned)