Skip to content

Conversation

@tychedelia
Copy link
Member

Sets up basic bevy App initialization and cross-FFI error handling.

Our strategy here is the following: Java should do any validation necessary before calling into the FFI layer. Errors are assumed to be unrecoverable and evidence of us doing something wrong. So we don't return error codes or anything but just check the error status as a string so we can at least throw a helpful exception for bug reports.

@tychedelia tychedelia requested a review from catilac October 16, 2025 20:59
tracing = "0.1"
tracing-subscriber = "0.3"
bevy = { version = "0.16", no-default-features = true, features = [
"bevy_render"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for wayland windowing we need to add "wayland" to the features array

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it's helpful, i can do it separately so i can actually test

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we'll def need more fleshing out here, i think there's a bunch of other stuff we'll want too. we're just generally going to be doing the "annoying" bevy integration version where we fine grain select what we want. this is to keep the final dylib small for packaging. see also the recently merged bevyengine/bevy#21472 which could be helpful for us.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that looks cool. maybe useful for per-target customization

Copy link
Collaborator

@catilac catilac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! I like the error approach too. And if we ever for whatever reason needed to share more details then we can just serialize more information.

I'm approving, but also curious about what things will look like, say, if they write an erroneous compute shader.

tracing = "0.1"
tracing-subscriber = "0.3"
bevy = { version = "0.16", no-default-features = true, features = [
"bevy_render"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that looks cool. maybe useful for per-target customization

*/
public static long add(long left, long right) {
return processing_h.processing_add(left, right);
private static void checkError() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this means we would need to poll the rust side for any errors?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup, this is a tedious consequence of ffi code. there are a few different c-style error patterns you can use, but they're all pretty manual. rust exceptions (panics) can't cross the ffi boundary (doing so is undefined behavior).

realistically, we'll probably only end up having like 20ish ffi functions. if we had hundreds, i'd suggest writing an annotation processor or some other kind of reflection magic in java to automate this.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay and there is no way from Rust to push an event into Java?

@tychedelia
Copy link
Member Author

I'm approving, but also curious about what things will look like, say, if they write an erroneous compute shader.

i think we'll def run into situations like this. what i'd propose is that we write a validate_shader ffi function that can eagerly check and return structured output. but also, there's nothing preventing us from returning a custom ffi error type for a given operation where it would be helpful, for example:

struct ValidationResult {
    error_code: u8,
    data: *const c_void,
}

in rust applications, you typically will bubble up Result using ? to a top level handler that will either log or panic. and so the pattern in this pr basically just ensure that we can reliably return results from our internal library code.

on the java side, we're using unchecked exceptions. right now it's just a general "something went wrong" exception class, but we could totally add an error code in addition to message and sub-type more on the java side if we do want to throw something like ValidationException.

@catilac catilac merged commit 33b8b52 into processing:the-wgpu-moment Oct 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants