Handling request_discard?

[OwlyCode]

Hi!

I'm using egui's Grids into my UI, and I've noticed that each time a new grid is rendered, there is a noticeable "glitchy" frame occuring. I've tracked this down to the fact that adding a new grid trigger a request discard:

// grid.rs:437

// The initial frame will be glitchy, because we don't know the sizes of things to come.

if ui.is_visible() {
    // Try to cover up the glitchy initial frame:
    ui.ctx().request_discard("new Grid");
}

It seems that when this is called, all rendering will stop (because the egui context switches to a special mode), causing the "glitchy" frame. I'm not sure on how this could be handled because all rendering happens in systems and we can't just re-run them. Would it be possible in that case to re-use the rendering from the previous frame?

Here's how it looks:

[vladbat00]

Hi! Sorry for the delayed response. You could try calling egui::Context::run manually and put all of your systems' code there. It handles discard by looping the passed run_ui lambda until the discards stop or the egui::Option::max_passes limit is reached. To use bevy_egui like that, you'll also need to set EguiContextSettings::run_manually to true.

See https://github.com/vladbat00/bevy_egui/blob/d351599b9a266eb52733eb842f535289dffd6297/examples/simple_multipass.rs.

That's probably not an ideal way to manage that, but atm bevy_egui doesn't offer a cleaner solution (and, so far, I'm not sure how one would look like).

[OwlyCode]

Hi! No problem I'm already lucky to have this library!

I'll see if I can do that. For now it was easier for me to skip using grids entirely: I'd have around 40 UI systems to move to achieve that.

[vladbat00]

I see. You might also find World::run_system useful, that way you'd have a &mut World system that would run your existing UI systems inside, without having to move too much code around. That basically involves only moving your UI systems from bevy app/schedule setup to the &mut World system.