wgpu(web) assertion failed: data.is::<T>()

[codeart1st]

Description
A follow up issue for #3430. wgpu still breaks for me on web with a minimal example.

https://github.com/codeart1st/wgpu-wasm-dispatch/blob/main/tests/test.rs

wasm-pack test --chrome

panicked at 'assertion failed: data.is::<T>()', /home/plange/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/25cb9f6/wgpu/src/context.rs:1045:5

Stack:

Error
    at http://localhost:8000/wasm-bindgen-test:1122:21
    at logError (http://localhost:8000/wasm-bindgen-test:219:18)
    at imports.wbg.__wbg_new_abda76e883ba8a5f (http://localhost:8000/wasm-bindgen-test:1121:66)
    at console_error_panic_hook::Error::new::h399b095a79993d2b (http://localhost:8000/wasm-bindgen-test_bg.wasm:wasm-function[3084]:0xc6a43)
    at console_error_panic_hook::hook_impl::hf541d198901b9961 (http://localhost:8000/wasm-bindgen-test_bg.wasm:wasm-function[540]:0x6171e)
    at console_error_panic_hook::hook::h0170f27b37365f4c (http://localhost:8000/wasm-bindgen-test_bg.wasm:wasm-function[3628]:0xce085)
    at core::ops::function::Fn::call::hd11bd76c5db1ccde (http://localhost:8000/wasm-bindgen-test_bg.wasm:wasm-function[2857]:0xc3218)
    at std::panicking::rust_panic_with_hook::h517db85e721544c2 (http://localhost:8000/wasm-bindgen-test_bg.wasm:wasm-function[1255]:0x9503e)
    at std::panicking::begin_panic_handler::{{closure}}::hf5155502a5ae718c (http://localhost:8000/wasm-bindgen-test_bg.wasm:wasm-function[1568]:0xa39e9)
    at std::sys_common::backtrace::__rust_end_short_backtrace::h17299e164873d32e (http://localhost:8000/wasm-bindgen-test_bg.wasm:wasm-function[3767]:0xcfc10)

[codeart1st]

Maybe it's because of wasm-bindgen-futures usage.

[Wumpf]

It's not that, it's that you created the surface through create_surface_from_canvas. Figured this out just now when trying to get egui to run on WebGPU :).
Calling create_surface with a canvas is a bit cumbersome but not terrible. Check what I had to do for that here:
emilk/egui@0b8780a

So it seems @grovesNL missed that method in his large fix PR #3657. I drilled already a little bit into the different surface creation methods but it's super confusing to me. Tbh I don't understands the original PR to entirely to begin with (so.. there's some object that shouldn't be owned by wgpu, otherwise everything breaks?) and it seems the return value types for surface creation are now all over the place.

[grovesNL]

@Wumpf thanks for spotting that! I figured we probably missed some cases but it's hard to spot because of all of the Anys now.

I opened #3718 which should fix this. Let me know if it's still not working because there may be other places too.

[codeart1st]

Thank you for looking into it.

I tried out your branch and it is working for me now. Integrationtest is green again: https://github.com/codeart1st/wgpu-layers/actions/runs/4770911276/jobs/8482505699

Because I have a "check wasm artifact size" job during build action, I found out that since 0.14.2 the artifact size changed significantly. The job failed with a 100kB compression threshold.

The size increased from 278kB to 322kB (+16%) and brotli compressed from 86kB to 100kB (+16%).

Is this relevant enough for a new issue or no priority for this project?

[Wumpf]

Confirmed it working as well for egui @grovesNL!