eframe/ egui-wgpu incompatibility with newer wgpu versions

[9SMTM6]

Describe the bug
In at least my build context (coming up), depending directly on wgpu version 20.1 (current) leads to a crash in Firefox (probably in all browsers that don't support WebGPU, it works on Chrome with enabled WebGPU). Heres the log in Firefox:

Uncaught TypeError: getObject(...) is undefined
    __wbg_requestAdapter_b0d64c10f0bfd226 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:578
    __wbg_adapter_42 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:250
    real http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:209
    __wbg_queueMicrotask_481971b0d87f3dd4 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:884
    __wbg_finalize_init http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:1559
    __wbg_init http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:1595
    async* http://127.0.0.1:8080/index.html#dev:16
mcmc_demo-6c401a0085eb0dce.js:578:30
    __wbg_requestAdapter_b0d64c10f0bfd226 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:578
    <wgpu::backend::webgpu::ContextWebGpu as wgpu::context::Context>::instance_request_adapter::hc0c16e57da346dd4 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2107636
    <T as wgpu::context::DynContext>::instance_request_adapter::hc0058abf52a1d763 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2202453
    h5cecfccf087c1a9a http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2166769
    hc389faf99ffaa202 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:105585
    h21410ab4be9f46b9 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:383964
    h35b40b5f68a3d1f0 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:661690
    hcf892b4c0a3a4fde http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:1181489
    h80f707863decb2cf http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2112313
    hbf9411c1172ab246 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:1678594
    <dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hfaed4a23f847ddbf http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2275128
    __wbg_adapter_42 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:250
    real http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:209
    (Async: VoidFunction)
    __wbg_queueMicrotask_481971b0d87f3dd4 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:884
    h51f0a1cca5739fc7 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:1850555
    h0eb3bde3985833bd http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2195678
    hc787f4c8a7bb596f http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2192491
    h76cc710eb39d210b http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:1700792
    h670841e24720bde5 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2250830
    h38ea8e899b4efd14 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2250778
    hf493d00ff565563f http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2167733
    h658afcf1f1425f65 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:1953734
    h486a59ce3e8054c5 http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2160407
    main http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2274002
    <anonymous> http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce_bg.wasm:2280141
    __wbg_finalize_init http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:1559
    __wbg_init http://127.0.0.1:8080/mcmc_demo-6c401a0085eb0dce.js:1595
    InterpretGeneratorResume self-hosted:1412
    AsyncFunctionNext self-hosted:799
    (Async: async)
    <anonymous> http://127.0.0.1:8080/index.html#dev:16

As said, executing this in at least the one browser that supports WebGPU on stable doesnt cause an error, and additionally matching the version of wgpu that egui depends on (that being 19.1) also fixes the issue with wgpu falling back to WebGL rendering.

The build-context is the eframe template with wgpu added (as feature and direct dependency), and of course no glow feature (though in earlier experimentation re-adding it did not make a difference), I also added the wayland feature, but I dont think that makes a difference.

I want the wgpu dependency because I want to render a custom shader.

So its run/build with trunk build.

Trying to run this with the master tree of egui and eframe leads to other runtime errors down the line.

Heres a diff between the state from the template and the issue that displays the error (if wgpu dependency is changed to 20.1): https://github.com/9SMTM6/mcmc-demo/compare/initial_template%E2%80%A6wgpu_dependency_issue

To Reproduce
Steps to reproduce the behavior (this has not been tested in its entirety):

1. Clone/ Apply the template
2. Add wgpu feature
3. Add wgpu dependency on 20.1 (with webgl feature to allow for fallback)
4. trunk serve
5. open the page on firefox, observe an empty page, check the browser logs and find an error similar to the above

Expected behavior
Essentially what happens if downgrade the dependency to 19.1, it detects that WebGPU is not enabled and falls back to WebGL rendering.

Alternatively at least some dependency resolution error, because there does seem to be a breaking change of wgpu but still some kind of dependency unification of the eframe/egui wgpu dependency with my direct one.

Screenshots

Not applicable

Desktop (please complete the following information):

• OS: Arch Linux
• Browser Firefox 126.0.1 (64-bit) | works with Chromium 125.0.6422.141 (Official Build) Arch Linux (64-bit) and the following flags: #enable-vulkan=true, #ozone-platform-hint=Wayland, #enable-unsafe-webgpu=true
• Version 0.27.2 and 0.27.0, master causes different runtime errors

Smartphone (please complete the following information):
not tested

Additional context

Cant think of anything else relevant.

[9SMTM6]

I've played a bit around with the egui_demo_app. Increasing the wgpu dependency of the egui workspace causes a few dependency issues (not just in cargo), but if you fix all these, the result works. Heres the commit with all changes: 9SMTM6@3d0c5cd.

This is certainly interesting, and maybe a hotfix for me (I'll test what happens if I patch egui to this version) but of course no permanent fix for this, this issue is likely to happen again when other changes are made to wgpu.

I'm still not sure what exactly is going on under the hood TBH. The wasm package process is fairly complex, perhaps theres some checks missing there. With the compiler errors I get, and looking at the way dependencies are declared in the Cargo.toml, its certainly not unifying these WGPU dependencies at rustc/cargo level. But perhaps its unifying some wgpu artifacts in the generated package?!

[9SMTM6]

Patching the template app dependencies on egui and eframe to use the version with the upgraded wgpu fixes the issue. Actually it fixes when directly depending on either wgpu version, but at this point I don't do anything with my wgpu dependency. I'd theorize that doing something with wgpu MIGHT cause the issue to re-appear (unless its really limited to the initialization, egui/eframe gets to that before me).

[9SMTM6]

Indeed, I get a very similar error in Firefox if I add the wgsl shader example to the latest state of the template that worked with both wgpu versions, and depend directly on 19.1.

Nice to have that nailed down. Still really not sure where things go wrong in the packaging.

Note that while upgrading to 20.1 isn't possible because of compiler errors.