Feature: webgl/stdweb backend

[Diggsey]

Using https://docs.rs/webgl_stdweb/0.1.0/webgl_stdweb/struct.GLContext.html

I've tried a couple of times to integrate this, but it's very non-trivial: obviously I'd like to reuse as much as possible from the GL backend, but it was never designed to have a separation between the code which translates GFX concepts into GL concepts, and the code which actually interacts with the OpenGL API.

[chpio]

is there a easy way to compile spirv_cross to wasm/include it in the build? also it would be really nice to run spriv_cross as a build step instead of including it into the build as a dependency.

[Diggsey]

I made some progress on this: I managed to create true C-like bindings to webgl by borrowing opengl.js from emscripten, running it through a custom-built preprocessor to handle the emscripten-specific macros and then incorporating that into a new stdweb-based gl-generator backend.

The net result is that I can call the normal OpenGL API on the wasm32-unknown-unknown target. Since then I've been working on extricating the dependency on winit from the gfx opengl backend.

[kvark]

@Diggsey u r da the best, man! Please keep up cracking this nut, we are excited to see this coming :)

[Boscop]

I'm also very interested in this, what's the current status of this? :)

[grovesNL]

@Diggsey is there a branch somewhere that contains your progress on this?

[cretz]

As an alternative to stdweb, consider the recently announced web-sys crate, e.g. canvas.get_context("webgl").unwrap().dyn_into::<web_sys::WebGlRenderingContext>()

[aep]

whats missing here, anything we can help with?

[luckielordie]

Is anyone working on this?

[kvark]

Looks like we are back to square one here, with @Diggsey disappearing. At least we can consider web-sys without risking of losing any work ;)

[eira-fransham]

I'm working on a Processing-like framework in Rust and this would be amazing to allow me to have an online sketchpad similar to a combination of https://valentin.dasdeck.com/processing/ and the Rust playground.

[luckielordie]

I'm planning on giving this a go with web-sys. Obviously it's a matter of time for me. Any help people could give me understanding the HAL Interface would be a major help.

[kvark]

@luckielordie HAL interface is basically Vulkan, plus a bit of type sugar in a few places.

[luckielordie]

@luckielordie HAL interface is basically Vulkan, plus a bit of type sugar in a few places.

I'm going to need to brush up on my Vulkan then!

[luckielordie]

A quick update, I've forked and created a branch here. If you want to contribute you're more than welcome to request access and I'll open it up. I'm fairly new to Rust so I'll always appreciate a more experienced eye.

[goddessfreya]

@luckielordie Might be preferable for maintainability reasons if you directly integrate webgl support into the gl backend, instead of having to separate backends.

[mmacedoeu]

I have also started some proof of concept using stdweb. I choose stdweb for two reasons: it has a broader scope with more stuff included and it plans to migrate to web-sys on the future.

So far I come to this challenging problems: spirv-cross should move to build.rs stage, glutin should be replaced with winit or plain stdweb, threads and structure like Starc should be rethought to web-friendly maybe just like crate yew use webworkers for concurrency.

I also a brand new backend instead of using gl, it may be possible to merge both in the end and use a lot of conditional compile flags but so far I am trying to just make things work and optimize latter on.

[kvark]

I also a brand new backend instead of using gl, it may be possible to merge both in the end and use a lot of conditional compile flags but so far I am trying to just make things work and optimize latter on.

wow, that sounds like a world of pain, tbh

Btw, what do you mean by "spirv-cross should move to build.rs stage"?

[mmacedoeu]

spirv-cross is a binding to native c/cpp lib so I think rustc will not be able to compite it to WASM, so you need to try to compile it (cross) using emsdk or just make all spirv to glsl transpile be done in build.rs pre-compilation stage so there is NO runtime translation done. Still I have not look into possible implications for this.

It really is a pain cave, any insights?

[grovesNL]

I also a brand new backend instead of using gl, it may be possible to merge both in the end and use a lot of conditional compile flags but so far I am trying to just make things work and optimize latter on.

I don't think we should need a lot of conditional compile flags for the gl backend, could we just use feature flags (optionally with a macro)? The function signatures should almost be the exact same between OpenGL ES (which we need to support anyway) and WebGL.

spirv-cross is a binding to native c/cpp lib so I think rustc will not be able to compite it to WASM, so you need to try to compile it (cross) using emsdk or just make all spirv to glsl transpile be done in build.rs pre-compilation stage so there is NO runtime translation done.

We need to allow runtime translation of SPIR-V to GLSL with spirv_cross, so it's not possible to do it all in build.rs. I think compiling the wrapper in spirv_cross to wasm is fine to start with. I can help with this - the wrapper exists in spirv_cross.

[grovesNL]

I have an experimental branch rendering the quad example using WebGL2 and web-sys (through the wasm32-unknown-unknown target). I hardcoded the shader for now because I don't have SPIRV-Cross in wasm yet.

I'll put the branch somewhere soon if anyone's interested, but there a few other issues we need to work through:

• We probably need to create some unified OpenGL/WebGL bindings for gfx (in a separate crate) to avoid use of #[cfg(target_arch = "wasm32")] etc. everywhere, and use a feature list to distinguish which functions are callable.
• A wrapper for the web-sys WebGL bindings would be useful to be able to pass references etc. For example, currently it's a bit difficult to work with raw web_sys::WebGlProgram because we really want to be able to use this in multiple places but it's not Copy (unlike gl::types::GLuint used now).
• As mentioned before we'll need to get the C++ SPIRV-Cross library (and the thin C wrapper in spirv_cross) to wasm through emscripten. Then we can build the Rust parts of spirv_cross to wasm32-unknown-unknown and call into the emscripten library.
• We need a simple way to create an event loop outside of winit, the boilerplate in web-sys for this is a bit noisy so maybe there is a crate that does this already, or we create something simple.
• Send and Sync bounds on the Backend trait are problematic right now for web-sys types mentioned above because they can't be shared with web workers. I simply disabled them in my experimental branch for the wasm32 target. But maybe there's a better way to deal with this for now. We could consider proxying calls from web workers to the main thread, but this is definitely not straightforward.
• (longer term) It would be useful to look into how to manage async resource loading (shaders, textures, etc.) to take full advantage of the web, this should reduce the initial bundle size of the generated wasm making it faster to parse/compile on first load.

We can probably start to split these into issues and address them individually.

Edit: I posted the branch here for reference https://github.com/gfx-rs/gfx/compare/master...grovesNL:webgl-hacking It's prototype quality at the moment (breaks the regular gl backends because of the temporary logging code, only supports quad, unformatted, etc.) but should give us some ideas about how to properly support it through the points mentioned above.

[icefoxen]

Awesome. I really don't have the time or energy to majorly contribute to this, but if it becomes a bit more mature I'll probably be trying to use it in ggez, which will probably result in lots of issues and hopefully attached fixes. :D

The event loop stuff is interesting, what do you need that winit doesn't provide? I was under the impression there was some pretty srs work in progress to make it possible to work more nicely on web already.

[grovesNL]

Yeah I plan to keep working through these issues for a while. I’m currently looking into the feasibility of a thin abstraction to combine WebGL and OpenGL types/signatures with some helpers we’ll need.

I’m not sure of the situation with winit/wasm support but that would be the ideal solution when it’s ready. I scanned the issue tracker a few days ago and it seemed like it was still planned or early WIP so didn’t try it out. If it’s already supported then that would be great. If it’s not supported yet, we could just have a simple wrapper to simplify the boilerplate for now.

[grovesNL]

A small update: I started investigating the first two points by creating abstractions over WebGL + OpenGL types/function signatures with primitive key types (which are Copy), and a simple render loop. My experiment is located at https://github.com/grovesNL/glow

There's an example in that repository that shows how the abstraction works at the moment. Also until we have something like winit on wasm to help with the event loop, events like key presses, resizing, etc. are still target-specific. Any feedback about this abstraction would be really helpful! If this experiment turns out to be useful then I should be able to quickly recreate my branch on top of it.

[icefoxen]

Looks pretty reasonable to me, from what little I know of such things. My only question would be, can you use a trait object rather than an enum for dispatching on WebGl1 vs WebGl2? I guess that would basically be splitting your WebRenderingContext into WebRenderingContextGl1 and WebRenderingContextGl2 and impl'ing RenderingContext for both.

Making winit work on wasm is something that the winit people rather want, but it looks like a bit of a beast of a change to make it work well. See https://github.com/tomaka/winit/issues/459 for the core issue, it seems.

[grovesNL]

Yeah definitely. I’m hoping this enum will mostly disappear if we could get wasm bindgen to automatically create a base trait for any common signatures. Maybe I could use a simple macro to avoid some of the repetition for now.

[grovesNL]

I've made some more progress in #2554 if anyone wants to take a look.

[erlend-sh]

Resolved by #2554?