You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to switch the default backend of eframe from glow to wgpu, making glow opt-in.
Background
eframe currently has two backends: glow and wgpu (pronounced "wiggipu").
glow is lightweight (few dependencies, compiles quickly), and wgpu is powerful (allows integrating more advanced 3D rendering alongside egui).
Having two backends is annoying for several reasons:
Duplicated code
Duplicated maintenance burden
We're spreading our resources
The last point in particular is what I want to address with this issue.
Why wgpu?
The broader graphics and GUI community is converging on wgpu as the standard graphics library for Rust. Bug fixes and improvements to wgpu makes everyones lives better.
Switching over to wgpu can also become a forcing function to improve the wgpu backend. For instance, if switching to wgpu increases the .wasm binary size, maybe that will motivate someone to fix it.
Worries with using wgpu as the backend
Increased compile times
This one sucks. I like light-weight crates, but it is hard to be light-weight and also powerful. We should measure and see how much worse it gets.
Increased wasm binary
wgpu shaders are written in WGSL (pronounces "wixel") and then transpiled to GLSL (never pronounced) when targetting the WebGL backend. This transpiling is done with naga. Naga is a chonky beast, because it has to be able to transpile any shader. This means the wasm binary size increases a lot.
I see two primary remedies:
Pre-compile the egui shaders to glsl so we don't need to ship naga
Summary
I'd like to switch the default backend of
eframe
fromglow
towgpu
, makingglow
opt-in.Background
eframe currently has two backends: glow and wgpu (pronounced "wiggipu").
glow is lightweight (few dependencies, compiles quickly), and wgpu is powerful (allows integrating more advanced 3D rendering alongside egui).
Having two backends is annoying for several reasons:
The last point in particular is what I want to address with this issue.
Why wgpu?
The broader graphics and GUI community is converging on wgpu as the standard graphics library for Rust. Bug fixes and improvements to wgpu makes everyones lives better.
Switching over to wgpu can also become a forcing function to improve the wgpu backend. For instance, if switching to wgpu increases the .wasm binary size, maybe that will motivate someone to fix it.
Worries with using wgpu as the backend
Increased compile times
This one sucks. I like light-weight crates, but it is hard to be light-weight and also powerful. We should measure and see how much worse it gets.
Increased wasm binary
wgpu shaders are written in WGSL (pronounces "wixel") and then transpiled to GLSL (never pronounced) when targetting the WebGL backend. This transpiling is done with naga. Naga is a chonky beast, because it has to be able to transpile any shader. This means the wasm binary size increases a lot.
I see two primary remedies:
WebGPU support is not yet universal, but its getting there: https://caniuse.com/webgpu
The text was updated successfully, but these errors were encountered: