WebGPU surface creation / basic app lifecycle #1302
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tychedelia
commented
Oct 22, 2025
| if (Platform.get() == Platform.MACOSX) { | ||
| return GLFWNativeCocoa.glfwGetCocoaWindow(window); | ||
| } else { | ||
| throw new UnsupportedOperationException("Window handle retrieval not implemented for this platform"); |
There was a problem hiding this comment.
@catilac We'll need to add wayland/x11 detection here for linux. Window I think should be pretty easy I just can't test right now.
There was a problem hiding this comment.
I'll get it going on wayland!
catilac
reviewed
Oct 24, 2025
| F: FnOnce() -> Result<T, ProcessingError> + panic::UnwindSafe, | ||
| { | ||
| // we'll catch panics here to prevent unwinding across the FFI boundary | ||
| panic::catch_unwind(|| match f() { |
There was a problem hiding this comment.
ooh good catch. i'll be sure to pay attention to this
| tracing = "0.1" | ||
| tracing-subscriber = "0.3" | ||
| bevy = { version = "0.16", no-default-features = true, features = [ | ||
| bevy = { version = "0.17", no-default-features = true, features = [ |
| ] } | ||
| thiserror = "2" | ||
| thiserror = "2" | ||
| raw-window-handle = "0.6" |
There was a problem hiding this comment.
is this a library to help us manage a raw window handle to pass into JVM world?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements the basic rendering lifecycle needed to drive bevy forward from the processing event loop.
When a
PSurfaceGLFWis created, we pass the window handle over ffi and import it into bevy. Bevy then will create the underlyingwgpusurface via its ordinary operations for windows. TheWindowhere we insert is a non-functional facade -- we'll make sure to synchronize it from the Java side but have no need atm to allow bi-directional communication (i.e. bevy resizes Glfw).There's some additional work we'll need to do to think about multi-window support. Right now we're driving the wgpu renderer forward in
endDrawonPGraphicsWebGPUbut this may not be correct in the presence of multiple graphics contexts.Basically, for implementing the main processing api, what we'll want to do is run all the user's functions to build up a frame's worth of abstract draw data on the Rust side (i.e. insert stuff into the ECS world as needed) and then run
updateonce at the end of frame which will drive the world forward one tick and present to the surface.GLFW + AWT = :(
GLFW does not play nice with AWT, especially on macOS where we have the requirement to run on the main thread. This is well documented including in this repo and will be an issue long term. Right now, I've chosen to just hard code disabling AWT when launching a sketch, but we'll need a more comprehensive solution here eventually.
How to test
Right now, I've only added support for macOS because I don't have my other machines to test on. But if you have a mac it should be pretty easy, just add a basic bevy scene to the app init. The next PR should implement our first basic actual rendering to test from Java.