hammypants
commented
11 months ago I am also seeing this. It looks like bevy_window can/will despawn window entities during the default Update schedule?
Open JoJoJet opened 11 months ago
hammypants
commented
11 months ago I am also seeing this. It looks like bevy_window can/will despawn window entities during the default Update schedule?
AntiBlueQuirk
commented
10 months ago My guess is that the Entity with the PrimaryWindow gets despawned when the window closes, taking the context with it. For me at least, the panic only happens for systems in the PostUpdate schedule. So you can probably fix this by moving your system to the Update schedule.
I think this is kind of a flaw in EguiContexts. Calling EguiContexts::ctx_mut implies that your system can only run if there is a context on the PrimaryWindow, but using EguiContexts as system parameter does not encode this condition to Bevy, since it uses Option<PrimaryWindow> internally. I think there should be a separate PrimaryEguiContext struct for running systems only when the primary contexts exists. Then, EguiContexts::try_ctx_mut() could be added that returns an Option, so that EguiContexts represents "contexts that may or may not exist, including the primary context".
An alternative temporary fix is to add a run condition to your system. This is a little silly, since you're running the same query twice, but it's a one line change until this gets resolved.
// In setup:
app.add_systems(PostUpdate, (
some_system.run_if(egui_has_primary_context),
))
// Elsewhere:
pub fn egui_has_primary_context(
query: Query<(With<bevy_egui::EguiContext>, With<bevy_window::PrimaryWindow>)>,
) -> bool {
!query.is_empty()
}
rlidwka
commented
5 months ago Can we have EguiContexts::try_ctx_mut() specifically to work around this issue?
mvlabat
commented
5 months ago Sounds good, I'll add it in the next release. Meanwhile, you can use the workaround suggested by @AntiBlueQuirk or use the following query, as in the two_windows example:
https://github.com/mvlabat/bevy_egui/blob/9dfe7076a96e09fc4d232dd5ddba60472f86ac90/examples/two_windows.rs#L69-L74
extrawurst
commented
2 months ago @mvlabat this did not make it in 0.28, right? i ran into this now after upgrading to 0.28.
mvlabat
commented
2 months ago @extrawurst the try_ctx_mut method is available since 0.27. If your system runs during the PostUpdate schedule, you should use it instead of ctx_mut to avoid the panic.
extrawurst
commented
2 months ago If your system runs during the PostUpdate schedule
but it does not 🤔 its regular Update schedule
mvlabat
commented
2 months ago @extrawurst is it consistent? Do you have a reproducible example?
extrawurst
commented
2 months ago nope not reliable reproducible, just like in the original posters case :(
extrawurst
commented
2 months ago its just the first time now that I got it after updating to bevy 0.14 and bevy_egui 0.28.
nixpulvis
commented
2 weeks ago I also have calls to ctx_mut panicking in an Update system. I replaced all the calls with if let Some(ctx) = ...try_ctx_mut() { ... } and now things aren't panicking, but IIUC once this issue is resolved, I won't need to?
meanbeanmachine
commented
1 week ago This might be a redneck workaround but I noticed that when I quit my app manually via a Quit button, I no longer received the panic messages. The panic messages only occur when I 'X' out the window. So I made this system to intercept the window close event, and close it the same way I do with the Quit button. Now the app never panics on window close.
fn window_exit_fix( close_requested: EventReader<WindowCloseRequested>, mut exit: EventWriter<AppExit>, ) { if !close_requested.is_empty() { exit.send(AppExit::Success); } }
I'm not smart enough to know why this works, but it does. On Ubtunu 22.04 at least. It doesn't fix whatever the issue is but I found it to be a better workaround vs using try_ctx_mut() in all of my egui systems.
This panic occurs intermittently when closing my app. Based on the panic message, I'm assuming that the
EguiContextfor the primary window is being deinitialized before the app fully closes, after which my system is allowed to run, which fails since it's trying to access an uninitialized context.Backtrace: