-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make egui work on WebGPU out of the box. #2945
Conversation
…e flag), workaround canvas creation issue
before: 6.62mb not too bad (: |
So WebGPU must be configured at compile-time to user either WebGL or WebGPU, but you cannot ever configure it so that you pick at runtime? So in effect we'll need to have a |
yes, that's my understanding of the state of things! |
confirmed that now: gfx-rs/wgpu#3119 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very cool!
It would be nice with a --webgpu
flag to scripts/build_demo_web.sh
so this can be easily tested
confirmed non-workaround path working with pending fix on wgpu |
BREAKING: Makes WebGL for wgpu opt-in. By default wasm builds for egui will now use WebGPU. To use WebGL, you need to add
wgpu = { version = "0.16.0", features = ["webgl"] }
now to yourCargo.toml
.Works around a surface creation issue which made any subsequent call to any method on the surface fail (in a rather arcane manner) - see gfx-rs/wgpu#3710
Regarding the breaking change: Wgpu doesn't allow both WebGPU and a "direct" backend, like WebGL, to live side by side (i.e. wgpu is either in a "wrap WebGPU" or "implement WebGPU" mode). Therefore, egui now inherits the webgl-opt-in behavior. Since Web is memory constraint and availability of WebGPU can be queried easily, two separate builds for WebGPU and WebGL seem to be desirable regardless, so I don't think this is a big issue.
Fixes #2137