Add egui_wgpu crate

[emilk]

Adding a new crate egui-wgpu as an official backend of eframe. This adds feature flags glow and wgpu to eframe, and you can enable either or both. At runtime you can select which backend to use with NativeOptions::renderer.

Forked from #1561 so I can make commits. Based on Nils Hasenbanck's egui_wgpu_backend with additions by @s-nie and myself.

I decided not to touch egui_wgpu/src/renderer.rs too much, and instead create a egui_wpgu::winit::Painter wrapper around it, abstracting all wgpu-specific code away from eframe. eframe now has two very similar-looking run_glow and run_wgpu.

Closes #1555 #1561

Name

egui-wgpu is already taken (https://crates.io/crates/egui_wgpu) by @LU15W1R7H, who was kind enough to transfer ownership of the crate name to me (just like they did for egui-winit!)

Other

I haven't tested the WGPU backend on web yet

[luiswirth]

exciting news!
Sure, we can do the same as with the egui-winit crate.
I'll transfer ownership to you @emilk. I've already sent you an invitation :).

[emilk]

That was quick - thanks @LU15W1R7H ❤️

[s-nie]

Works great. Thanks for integrating this so quickly!

How should we treat the feature flags for this?

If in any way possible, enabling both of them at the same time should be an option. This will let users create an app where the backend can be selected at runtime. Building with two backends might seem redundant at first, but in my experience, glow and wgpu complement each other pretty well in that one of them always works, even if the other doesn't because of platform incompatibility.

[s-nie]

Love the approach with the Renderer struct. Can we derive serde::Deserialize and FromStr for it? For config and command line parsing.

impl FromStr for Renderer {
    type Err = Box<dyn std::error::Error>;

    fn from_str(name: &str) -> Result<Self, Self::Err> {
        match name.to_lowercase().as_str() {
            #[cfg(feature = "glow")]
            "glow" => Ok(Self::Glow),
            #[cfg(feature = "wgpu")]
            "wgpu" => Ok(Self::Wgpu),
            _ => {
                let message = format!(
                "Backend '{name}' is not available. Make sure that the corresponding feature is enabled."
            );
                Err(message.into())
            }
        }
    }
}

[Pjottos]

I believe the creation of the wgpu::Surface is unsound. The docs for wgpu::Instance::create_surface state:

Safety

• Raw Window Handle must be a valid object to create a surface upon and must remain valid for the lifetime of the returned surface.

The raw handle should be valid since it is part of the winit window, but the window is not guaranteed to outlive the surface.

There is a proposal for making the API safe (gfx-rs/wgpu#1463) but it doesn't seem like it will be implemented any time soon.

[emilk]

@Pjottos good catch, but hard for us to fix. I guess the best we can do is make egui_wgpu::Painter::new unsafe and document this problem.

[emilk]

If this looks good I will merge and also publish 0.18 of egui-wgpu to get it up-to-date.

[s-nie]

Looks good to me! Thanks again :)

[MarijnS95]

While randomly going through this Cargo.toml, there's a puffin = ["dep:puffin", "egui_glow/puffin"] that enables this optional egui_glow now whenever puffin is enabled. I think the feature is only used to emit profiling scopes in that crate, should it perhaps be updated to egui_glow?/puffin?

[emilk]

good catch; will fix

[emilk]

fixed in d76d055

[MarijnS95]

Thanks! I still had a little entry for this on my TODO list (to not forget), can be crossed off now :)