You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Buffers are exposed as &mut [MaybeUninit<u8>], see NativeWindowBufferLockGuard::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 in buffer_mut.
The surface is both unlocked and presented in NativeWindowBufferLockGuard::drop, whereas Softbuffer allows these two steps to be separate (e.g. you can Drop an in-progress Buffer<'_> and request a new one in Surface::buffer_mut, with no side-effects).
There's a few things that make zero-copying difficult on Android:
RGBXformat instead ofBGRX. Should be fixed by github.com/AddPixelstruct andPixelFormatenum #289.Buffer::byte_strideand use it on Android #315.&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.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
SurfaceControlstuff @MarijnS95 is working on will allow fixing the last point?