Why does this crate not use egui-wgpu and egui-winit

[IceSentry]

Like the title says, why is this crate not using the official helper libraries egui-wgpu and egui-winit? I use them in my own renderer project and the integration with egui becomes tiny. I understand that bevy_egui does a bit more things like exposing a way to use Handle<Image> but it seems like the crate could be a lot simpler if it uses those helper crates.

Is the reason simply that these didn't exist when the crate was originally made?

If there's any interest I could consider making a PR to use those crates instead of all the manual integration work but I don't want to do it before knowing if there's a reason why it wasn't already done.

This bevy PR would make the integration with egui-winit even simpler bevyengine/bevy#15884

[vladbat00]

Hi! Hm, that is an interesting question. I guess, the biggest reason was that these crates weren't around when the first version of bevy_egui was released. :D At least that's what crates.io says, maybe one of those was there as an example integration but not as a separate crate? I'm not sure, but I guess that's not very important.

But the real reason is that I've just never considered it. Can either of those crates be re-used to implement a Bevy integration? I've always thought of Bevy as a separate backend (from the integration perspective), even though it uses winit and wgpu under the hood, it provides its own high level wrappers. And they seem to be more straightforward to use, considering it's a Bevy integration in the first place: you have input events, you have a render graph, you have systems pushing updates to Egui and then rendering its output - it all sticks together quite naturally.

If we use winit directly, does that mean that we'll start reading input events and render Egui jobs directly via winit and wgpu, bypassing Bevy? I see how it can be beneficial from the code re-use perspective, which will also make us closer to the reference implementation. Are there other benefits? And what will be the drawbacks?
If I made the wrong assumption and by using those crates as helpers you meant something else, please correct me.

I understand that bevy_egui does a bit more things like exposing a way to use Handle<Image>

I also hope to rework the input system in some near future, to improve the whole "world-space UI" story. We can already render Egui to images (which can be used as material textures for meshes), but we can't really interact with world-space UI. Since Bevy 0.15 has integrated bevy_mod_picking, I think we can finally make it possible for bevy_egui users.

Having that said, I'm not opposed to the idea of depending on either of those crates if bevy_egui can benefit from it. It's been a while since I peeked in either egui-wgpu or egui-winit, so I don't really know how exactly bevy_egui could incorporate those. But if you have an idea of how that can work, feel free to put up a draft PR, we can definitely consider it.

[IceSentry]

So, I've been using those crates in a custom renderer I've been working on that uses bevy for everything else. I'm pretty confident that we could use egui-wgpu to deal with all the rendering parts because bevy already exposes all the relevant wgpu parts. We'd still need things like a custom Node to interact with the render graph correctly but it would simplify a lot of the rendering related code.

For egui-winit, right now it's not ideal because it assumes you have access to the raw winit event stream. This is not currently the case in bevy so what I do in my project is that I listen to all the relevant events and then send fake winit events to the egui-winit integration. This is not ideal because some of those events have internal data that you can't easily construct and I currently use unsafe for that. The PR I linked should expose everything needed though, so once we have that it becomes a lot easier to integrate winit. The benefits on this one are a bit less clear to me because I'm not 100% sure it will work properly with things like world-space UI.

I think the first step would be to try to integrate egui-wgpu first and see how it goes. The only thing I'm not sure is if it will work correctly for all the camera driven stuff bevy does. In my project I just render to the swapchain directly, but that's all configurable.

I'll throw up a PR in the next couple of days for egui-wgpu and we can see if it's worth pursuing.

[aevyrie]

IMO the input system should remain independent of winit. World space UI is a good example, the inputs aren't always going to come from the window, you often want to control that interface, or inject inputs for testing.

[vladbat00]

@IceSentry that would be great, thank you! Just a heads up, I've just pushed a PR with a refactor of EguiNode I wanted to perform a long time ago. I guess you'll want to base your changes from that branch: #325. Sry about the timing :D