Architecture for bevy_egui update for multi-window

[anderspitman]

@shanecelis no need to look at this until next week, but I wanted to get it down while it's fresh.

Current situation

• bevy_egui introduced a breaking change in 0.35.0. EguiContext components are no longer automatically attached to windows. Instead, they need to be attached to Cameras, and only the first spawned camera is set up automatically. See here and here.
• Our recent multi-window changes require us to manage some of this complexity ourselves in order to update bevy_egui to 0.35.0+.

Root problem

The official way to have multiple windows with bevy_egui is by creating a separate EguiMultiPassSchedule for each window. See the example here.

The problem with that approach for us is that we render our UI for all windows in a single system that loops through our windows, whereas that example uses separate systems for each window. A corollary is that the separate schedules are hard-coded, where we need to be able to spawn an unknown number of windows at runtime. I've opened an issue upstream asking what the recommended way to do this is.

I believe I have tortured the Rust type system into something that could work with our current architecture, but it feels extremely hacky. The code is here. I'm hoping this can be a starting point of coming up with something cleaner.

The main downside with my current approach is that you have to hard code an upper limit on the number of concurrent windows, with lots of duplicated code. Maybe we can get around it with generics or something, but the whole thing is just gross.

One potential alternative would be to change our architecture so each window runs in it's own system. I believe that would entail creating custom schedules dynamically at runtime and attaching instances of our window system to it. I haven't experimented much with this design.

Anyway, here's my code: https://github.com/anderspitman/bevy_egui_multi_window

[shanecelis]

This is great Anders. I love the small discovery programming code project you've got. I'm curious what's in their schedule? How many systems are in there? If it's only a few, we can probably just call them ourselves.

On Monday for the code that you have working here what I'd try is this: modify your a window_sys to accept an input identifying your context (In<Entity> maybe?). Then in a new system that loops over all your contexts, call commands.run_system_cached_with(window_sys, gui_context_id). See if that gets you out of the current fixed-limit code duplication.

[anderspitman]

I'm curious what's in their schedule? How many systems are in there?

I don't think the schedule actually has any systems connected to it, other than those we add ourselves. It's purpose appears to be to separate EguiContext instances so they run on different schedules.

[anderspitman]

Thinking about your second paragraph gave me an idea. Gonna go try something.

[anderspitman]

Idea didn't work. I believe the crux of the problem is this:

The only way to dynamically add_systems at runtime is by creating a concrete schedule with Schedule::new() and then calling add_system on that object. However, I don't see any way to integrate a concrete object with bevy_egui's scheduling logic, which is all based on labels. I think most of the relevant code is in this function: https://github.com/vladbat00/bevy_egui/blob/8c662bc7769cd9e3b68f96293c246229675c0bfe/src/lib.rs#L1722

[shanecelis]

I looked at the Egui example code a little more carefully. I wonder if we changed the argument from this function

fn ui_second_window_system(
    mut egui_user_textures: ResMut<EguiUserTextures>,
    mut ui_state: Local<UiState>,
    mut shared_ui_state: ResMut<SharedUiState>,
    images: Res<Images>,
    mut egui_ctx: Single<&mut EguiContext, Without<PrimaryEguiContext>>,
) {

to mut egui_ctx: Query<&mut EguiContext, without<PrimaryEguiContext> if that would fix us up.

[anderspitman]

I did try something along those lines in my experimentation. The problem is that you end up looping through multiple EguiContext, but the run of ui_second_window_system is only valid for one of them, namely whichever one of them is scheduled with add_systems.

EguiContext can not share schedules. That check is hard coded in bevy_egui here.

What my code does is guarantee each context has it's own schedule, and that each run of window_sys only processes whatever context cooresponds to the schedule used to call that specific invocation of window_sys.

[shanecelis]

Thank you for the link. That appears to be a restriction only for multi-pass mode. Do we use multi-pass mode?

[shanecelis]

I will try to alter your example to draw both windows with essentially one system if I can as a proof of concept.

[anderspitman]

Thank you for the link. That appears to be a restriction only for multi-pass mode. Do we use multi-pass mode?

Historically we actually didn't use multipass, but it looks like singlepass is planned to be deprecated by bevy_egui: https://github.com/vladbat00/bevy_egui/releases/tag/v0.35.0

If that solves our problem maybe they won't deprecate it though.

[shanecelis]

They have made it tricky over there in bevy_egui. I did take your example and tried to hone in down in many different ways, probably ways that you first tried, to make it data driven, but it's still fixated on a unique schedule. However, I did find that using a const type can be unique. My version is over here.