Repository navigation
Zero-copying on Android #318
Description
There's a few things that make zero-copying difficult on Android:
- Buffers are in
RGBXformat instead ofBGRX. Should be fixed by github.com/AddPixelstruct andPixelFormatenum #289. - Buffers have stride. Should be fixed by Add
Buffer::byte_strideand use it on Android #315. - Buffers are exposed as
&mut [MaybeUninit<u8>], seeNativeWindowBufferLockGuard::bytes. Is this really necessary, or could we rely on the buffer being zero-initialized? If not, we'll have to do a zeroing step ourselves inbuffer_mut. - The surface is both unlocked and presented in
NativeWindowBufferLockGuard::drop, whereas Softbuffer allows these two steps to be separate (e.g. you canDropan in-progressBuffer<'_>and request a new one inSurface::buffer_mut, with no side-effects).
Maybe the SurfaceControl stuff @MarijnS95 is working on will allow fixing the last point?
Activity
MarijnS95 commentedon Jan 23, 2026
For the last point: I'm curious what happens if
lock()is called twice withoutunlock(); i.e. dropping the buffer while forgetting to present it, ifdrop()->unlock()didn't do both automatically. It may seem the Android API doesn't allow this.That branch surely solves it, but has high Android requirements (most API was added in 29, but a bugfix to use it on the root
NativeWindowsurface only got accepted in 35). I'll open a PR either way to discuss the details and not forget about it.MarijnS95 commentedon Feb 1, 2026
What happens if I
std::mem::forget(buffer)in place ofbuffer.present(), the secondlock()` fails: