egui-wgpu api design

[luiswirth]

In my opinion there are a couple of flaws with the current egui-wgpu api.

(Note: I'm going to use the new names from #2021)

I had a discussion with some folks from wgpu and we came to the conclusion, that there shouldn't be a Renderer::render that creates it's own render pass. You should always have to give in your own render pass. So Renderer::render_onto_renderpass would become Renderer::render and the current Renderer::render would be removed.
Every time egui-wgpu is used directly the user should create it's own render pass and adjust it to their needs (msaa, depth texture, etc). This would also allow us to remove things like the depth texture from here and only have eframe care about it. egui-wgpu shouldn't care about this.

Also the winit feature of egui-wgpu is weird in my opinion. egui-wgpu should only be a thin wrapper around a wgpu::RenderPipeline together with some resources. It should only care about wgpu. The combination of wgpu and winit should be handled outside of this crate. For instance in eframe or some other crate like my old eww (egui + winit + wgpu) crate.
(I also believe that eframe should entirely depend on egui-winit for both web and native, but that's a different issue #2023 )

I think a clear separation of these things would really help, because right now I don't like the api I'm presented with when creating my own integration without eframe.

(Also issue number #2022 😆)

[coderedart]

I am trying to come up with an alternative design in https://github.com/coderedart/etk

it has WindowBackend and GfxBackend traits that backends can implement. and a UserApp trait which can be generic over the two traits. for those who want to use the specific backends (winit + wgpu for example), can just directly use those times and do custom rendering or stuff like that.

[luiswirth]

@coderedart That sounds great! I will take a look :)

[emilk]

Sounds good to me!

egui-wgpu/src/winit.rs exists so that users can easily use it with egui-winit without having to use eframe (e.g. for more control).

Other contributors to egui-wgpu might have some opinions here, including @s-nie @rib @expenses

[expenses]

I had a discussion with some folks from wgpu and we came to the conclusion, that there shouldn't be a Renderer::render that creates it's own render pass. You should always have to give in your own render pass. So Renderer::render_onto_renderpass would become Renderer::render and the current Renderer::render would be removed.

Also the winit feature of egui-wgpu is weird in my opinion. egui-wgpu should only be a thin wrapper around a wgpu::RenderPipeline together with some resources. It should only care about wgpu. The combination of wgpu and winit should be handled outside of this crate. For instance in eframe or some other crate like my old eww (egui + winit + wgpu) crate.

This sounds good to me.

[Wumpf]

So Renderer::render_onto_renderpass would become Renderer::render and the current Renderer::render would be removed.

That part got implemented.
What's still left to do here is to split out the winit binding out.

It might make sense to have a crate that just takes care of winit and then in turn has features for supporting different rendering backends - ideally through a shared interface.