-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use new NativeWindow::lock()
API in dummy_render()
#7
base: main
Are you sure you want to change the base?
Conversation
e7a8ba9
to
0cd504c
Compare
Some(HardwareBufferFormat::R8G8B8A8_UNORM), | ||
) | ||
.unwrap() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be good to have a comment explaining what this is for.
This is intended to be a bare-bones example of how to use android-activity so it's quite likely someone looking at this isn't going to be familiar with what set_buffers_geometry
does (and the name from the NDK isn't very self documenting when we're using it to set the format and not the 'geometry' as such).
Maybe we can just note that, since this example is going to clear the window from the CPU then we want to ensure the buffer is in a known format that we will be able to write to from dummy_render()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, still a draft as I wanted to share progress and show what's possible with the new bindings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I'd be happy to have a convenient way to at least show something other than a black screen, but without needing to pull in a full-blown graphics API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool cool, this already shows a gradient instead of a black screen, as a sign of life.
We can probably drop the draft status now, IIRC this is mostly ready.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah don't mind if it's taken out of draft and will just want to wait until it doesn't depend on [patches]
before landing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, expect that to take ±1month though. That should be enough time to see if there are any issues with this patch though, pretty helpful to test compatibility with the ecosystem meanwhile.
6cb5bd1
to
22450a7
Compare
NativeWindow::lock()
API NativeWindow::lock()
API in dummy_render()
c5954d6
to
15a558b
Compare
app.input_events(|event| { | ||
app.input_events_iter().unwrap().next(|event| { | ||
info!("Input Event: {event:?}"); | ||
InputStatus::Unhandled | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rib this next()
function returns a bool
. Are we supposed to run it in a while
loop, and if so can you put that in the doc-comment and give this function #[must_use]
to make it (much!) harder to overlook?
ce6eecf
to
455ddd6
Compare
No description provided.