ndk/native_window: Add lock() to blit raw pixel data
#404
Conversation
|
Hehe, did you maybe also see me using Yeah, in particular it was too much of a faff in that context to also deal with getting the bytes per-pixel which you really need to do anything with the buffers from the CPU since the API is pretty ghastly and doesn't tell you the size of the buffer in bytes - you have to work it out based on the pixel format. Blob doesn't need to be |
|
No I did not, this is actually a commit from almost 1 year ago (d104d01) that I just kept postponing to contribute back, because I didn't know what to do with the |
|
Regarding Also bpp is generally in bits, shall I change this to return bits instead of bytes? |
|
bpp is just ambiguous - definitely wouldn't assume either way without looking for context. bytes seems fine here. There are some missing format that could be good to fill in for completeness here. e.g. AHARDWAREBUFFER_FORMAT_R10G10B10A10_UNORM = VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 which is 8 bytes per pixel:
|
nice coincidence then I wanted to be able to clear the framebuffer at least when doing that but also didn't want to be inlining a bunch of byte-per-pixel format mappings just for that. |
|
|
oh, curious. I was looking here https://developer.android.com/ndk/reference/group/a-hardware-buffer#ahardwarebuffer_format |
|
Docs are typically ahead, guess they come with NDK r26. There's no Android version compatibility listed in the docs, though, so I assume 26 because that's when the non-legacy formats were added. |
right that's probably the appropriate thing here. that might be a handy utility for testing but probably doesn't belong as part of the |
ndk/src/native_window.rs
Outdated
| /// returns it is updated (commonly enlarged) with the actual area the caller needs to redraw. | ||
| pub fn lock( | ||
| &self, | ||
| dirty_bounds: Option<&mut ffi::ARect>, |
There was a problem hiding this comment.
I would avoid having a mutable reference like this if all possible. I would pass in a rectangle and then return a rectangle as a tuple with the lock.
There was a problem hiding this comment.
I instead considered putting it in the returned guard.
There was a problem hiding this comment.
Done that now, but it might make it less clear that when the user passes this to the function, they have to read back the updated value from NativeWindowBufferLockGuard. But that would be the same (except for still having &mut) when they already define their local variable mut for other reasons.
| } | ||
|
|
||
| /// The actual bits. | ||
| pub fn bits(&mut self) -> *mut std::ffi::c_void { |
There was a problem hiding this comment.
Maybe it would be possible to have a function that returns a mutable slice instead of a pointer?
There was a problem hiding this comment.
I had considered that, and especially in the context of softbuffer it is UB to cast a pointer to a safe slice, since these APIs are mostly for writing to memory.
It'll have to be &mut [MaybeUninit<u8>].
There was a problem hiding this comment.
@notgull done this now. Perhaps it is also interesting to add API's that give access to individual scanlines, by offsetting the pointer by stride() * num_rows * bpp and giving the user only a slice of length width() * bpp? And then wrap that in an iterator again so that it becomes very natural to update pixels?
That won't help for softbuffer though which currently assumes contiguous memory.
MarijnS95
force-pushed
the
window-lock
branch
3 times, most recently
from
da75940 to
c8ba8e6
Compare
There was a problem hiding this comment.
I'm not entirely convinced that having the separate API for getting the modified dirty bounds from the lock ends up being better than the &mut argument.
My nagging concern would probably be that it's now easier to miss the fact that if you do pass a dirty bounds you need to additionally remember to query back the modified bounds - whereas with the &mut argument, even if a developer hadn't fully appreciated that the region might get expanded they will any way probably reference the correct region in their code.
Either way is workable though and this is a fairly low-level detail so this seems reasonable enough to me.
Apart from that, everything else looks good to me.
|
Thanks @rib. I've reverted that suggestion from @notgull now as I indeed agree that when a user is forced to pass It is only a problem when someone requests explicit bounds anyway, most might just pass I've also added the per-line iterator API hinted at above and tested it out in: https://github.com/rust-mobile/rust-android-examples/compare/na-pixels-lock Rust's |
For rust-windowing/softbuffer#44, CC @notgull