Unify lifetime handling for NativeWindow and HardwareBuffer
#309
Labels
difficulty: average
Likely as difficult as most tasks here
priority: low
Nice to have
status: needs investigation
Issue must be confirmed and researched
type: enhancement
Wouldn't this be the coolest?
Comments
MarijnS95
added
type: enhancement
MarijnS95
added a commit
that referenced
this issue
Aug 11, 2023
When implementing proper ownership `acquire()` and `release()` semantics for `NativeWindow` in #207, I thought I had checked all existing calls to `NativeWindow::from_ptr()` to make sure that they return a pointer that we get ownership over, and have to clean up ourselves. This turns out to [not be the case for `AImageReader_getWindow()`]: The ANativeWindow is managed by this image reader. Do NOT call ANativeWindow_release on it. Instead, use AImageReader_delete. And can be trivially reproduced by creating an `ImageReader` and calling `.get_window()`. Dropping the `NativeWindow` is fine but subsequently dropping the `ImageReader` results in a NULL-pointer SEGFAULT. For now calling `clone_from_ptr()` is enough to first acquire an extra reference on the pointer so that ownership remains balanced, but in the future we'd like to investigate a [new non-owned `NativeWindow` type similar to `HardwareBuffer`]. As of writing the following calls to `from_ptr()` remain, that are all confirmed to transfer ownership and require cleanup via `_release()`: - `ASurfaceTexture_acquireANativeWindow()`; - `AMediaCodec_createInputSurface()`; - `AMediaCodec_createPersistentInputSurface()`; - `ANativeWindow_fromSurface()`. [not be the case for `AImageReader_getWindow()`]: https://developer.android.com/ndk/reference/group/media#aimagereader_getwindow [new non-owned `NativeWindow` type similar to `HardwareBuffer`]: #309
MarijnS95
added a commit
that referenced
this issue
Aug 15, 2023
When implementing proper ownership `acquire()` and `release()` semantics for `NativeWindow` in #207, I thought I had checked all existing calls to `NativeWindow::from_ptr()` to make sure that they return a pointer that we get ownership over, and have to clean up ourselves. This turns out to [not be the case for `AImageReader_getWindow()`]: The ANativeWindow is managed by this image reader. Do NOT call ANativeWindow_release on it. Instead, use AImageReader_delete. And can be trivially reproduced by creating an `ImageReader` and calling `.get_window()`. Dropping the `NativeWindow` is fine but subsequently dropping the `ImageReader` results in a NULL-pointer SEGFAULT. For now calling `clone_from_ptr()` is enough to first acquire an extra reference on the pointer so that ownership remains balanced, but in the future we'd like to investigate a [new non-owned `NativeWindow` type similar to `HardwareBuffer`]. As of writing the following calls to `from_ptr()` remain, that are all confirmed to transfer ownership and require cleanup via `_release()`: - `ASurfaceTexture_acquireANativeWindow()`; - `AMediaCodec_createInputSurface()`; - `AMediaCodec_createPersistentInputSurface()`; - `ANativeWindow_fromSurface()`. [not be the case for `AImageReader_getWindow()`]: https://developer.android.com/ndk/reference/group/media#aimagereader_getwindow [new non-owned `NativeWindow` type similar to `HardwareBuffer`]: #309
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See #296 (comment), there are multiple ways we can approach this.
Something based on borrows (Like how
String+&strwork together) has my preference, but we can't give any sensible lifetime to for example whatfn native_window()returns (which we currently have to forcibly_acquireto make it valid). Alas, we'll probably remove thosestaticgetters anyway in light of recent suggestions and to support multi-Activity, so this specific case wouldn't affect us anymore. At which point a borrow-based approach might as well work out :)The text was updated successfully, but these errors were encountered: