Struct EguiPlugin

pub struct EguiPlugin {
    pub enable_multipass_for_primary_context: bool,
}

Adds all Egui resources and render graph nodes.

Fields

enable_multipass_for_primary_context: bool

About Egui multi-pass mode

From the Egui documentation:

By default, egui usually only does one pass for each rendered frame. However, egui supports multi-pass immediate mode. Another pass can be requested with egui::Context::request_discard.

This is used by some widgets to cover up “first-frame jitters”. For instance, the egui::Grid needs to know the width of all columns before it can properly place the widgets. But it cannot know the width of widgets to come. So it stores the max widths of previous frames and uses that. This means the first time a Grid is shown it will guess the widths of the columns, and will usually guess wrong. This means the contents of the grid will be wrong for one frame, before settling to the correct places. Therefore Grid calls egui::Context::request_discard when it is first shown, so the wrong placement is never visible to the end user.

Usage

Set this to true to enable an experimental support for the Egui multi-pass mode.

Enabling the multi-pass mode will require your app to use the new EguiContextPass schedule:

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugins(EguiPlugin { enable_multipass_for_primary_context: true })
        .add_systems(EguiContextPass, ui_example_system)
        .run();
}
fn ui_example_system(contexts: EguiContexts) {
    // ...
}

If you create multiple contexts (for example, when using multiple windows or rendering to an image), you need to define a custom schedule and assign it to additional contexts manually:

#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
pub struct SecondWindowContextPass;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugins(EguiPlugin { enable_multipass_for_primary_context: true })
        .add_systems(Startup, create_new_window_system)
        .add_systems(EguiContextPass, ui_example_system)
        .add_systems(SecondWindowContextPass, ui_example_system)
        .run();
}

fn create_new_window_system(mut commands: Commands) {
    commands.spawn((Window::default(), EguiMultipassSchedule::new(SecondWindowContextPass)));
}

fn ui_example_system(contexts: EguiContexts) {
    // ...
}

In the future, the multi-pass mode will likely phase the single-pass one out.

Note to developers of public plugins

If your plugin depends on bevy_egui, here are some hints on how to implement the support of both single-pass and multi-pass modes (with respect to the EguiPlugin::enable_multipass_for_primary_context flag):

• Don’t initialize EguiPlugin for the user, i.e. DO NOT use add_plugins(EguiPlugin { ... }) in your code, users should be able to opt in or opt out of the multi-pass mode on their own.
• If you add UI systems, make sure they go into the EguiContextPass schedule - this will guarantee your plugin supports both the single-pass and multi-pass modes.

Your plugin code might look like this:

pub struct MyPlugin;

impl Plugin for MyPlugin {
    fn build(&self, app: &mut App) {
        // Don't add the plugin for users, let them chose the default mode themselves
        // and just make sure they initialize EguiPlugin before yours.
        assert!(app.is_plugin_added::<EguiPlugin>());

        app.add_systems(EguiContextPass, ui_system);
    }
}

fn ui_system(contexts: EguiContexts) {
    // ...
}

Trait Implementations

impl Plugin for EguiPlugin

fn build(&self, app: &mut App)

Configures the App to which this plugin is added.

fn finish(&self, app: &mut App)

Finish adding this plugin to the App, once all plugins registered are ready. This can be useful for plugins that depends on another plugin asynchronous setup, like the renderer.

fn ready(&self, _app: &App) -> bool

Has the plugin finished its setup? This can be useful for plugins that need something asynchronous to happen before they can finish their setup, like the initialization of a renderer. Once the plugin is ready, finish should be called.

fn cleanup(&self, _app: &mut App)

Runs after all plugins are built and finished, but before the app schedule is executed. This can be useful if you have some resource that other plugins need during their build step, but after build you want to remove it and send it to another thread.

fn name(&self) -> &str

Configures a name for the Plugin which is primarily used for checking plugin uniqueness and debugging.

fn is_unique(&self) -> bool

If the plugin can be meaningfully instantiated several times in an App, override this method to return false.