Skip to content

Conversation

@tychedelia
Copy link
Member

Adds initial support for PImage backed by a bevy::image::Image. This doesn't include everything we'll need, just enough to render a background image to demonstrate the basic flow works.

Some important implementation notes:

  • We're choosing to store everything as an Entity rather than expose Handle<Image> to users. This allows us to have a consistent return type across FFI for anything stored in the ECS. PImage stores a variety of things useful for interacting with an image, most notable including a readback staging buffer for us to copy it into. This is expensive (basically doubles the cost of every texture in vram) but avoids having to allocate on demand when the user calls loadPixels. We can add more intelligent deferral/caching later.
  • Note the pattern used in image.rs. In short, to avoid annoying borrowing errors when interacting with &mut World, we create a one-off system that we call instead, which allows Bevy to do the validation at runtime that our borrows are okay. A basic sketch of how this works:
fn our_fancy_function(world: &mut World, foo: u32, bar: Entity) -> Result<()> {
    fn our_fancy_function_inner(In(foo, bar): In(u32, Entity), baz: Res<Baz>, quxes: Query<&Qux>) {
        // do something ...
        Ok(())
    }

    world.run_system_cached_with(new_inner, (foo, bar)).unwrap()
}

You may not have seen systems with In parameters and return arguments, but systems can accept context this way when called directly! Note that the cached on the world.run_system_cached_with means that the system is registered behind the scenes so its query will be cached.

Minor notes:

  • I changed create_surface to surface_create to properly namespace things in our FFI layer. We'll probably want to go even further here just for good measure (i.e. processing_graphics_begin_draw) but that's for another PR.

@tychedelia tychedelia requested a review from catilac November 26, 2025 01:53
@catilac
Copy link
Contributor

catilac commented Nov 26, 2025

Some of the imports have changed, and I think the linux code paths need to namespace c_void.
After I put that in I got this unwinding exception, only posting the message for now and not trace:

thread 'main' panicked at /home/moon/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/glfw-0.59.0/src/lib.rs:637:5:
GLFW Error: Wayland: Focusing a window requires user interaction
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread 'main' panicked at library/core/src/panicking.rs:225:5:
panic in a function that cannot unwind
stack backtrace:

I'm happy to help with this in a separate PR, but still need to dig into which change affects wayland

Copy link
Contributor

@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.

Yay, okay this works! The build is broken due to the c_void namespacing issue I mentioned. Once build passes this is good to go

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.

2 participants