Gfx: Emscripten compatibility

[kvark]

The way is clear now: http://bl.ocks.org/AerialX/26f81381b0b47c506959

[kvark]

@AerialX Please let us know if there is anything else that you found not functioning. Current issues should be resolved now with #642 and #643

[AerialX]

Besides those, I just ran into few minor WebGL compatibility things.

• GL_DRAW_FRAMEBUFFER and GL_READ_FRAMEBUFFER aren't valid framebuffer targets. Only GL_FRAMEBUFFER is allowed.
• glPolygonMode doesn't exist.
• info::parse() chokes on "WebGL 1.0". Version numbers also aren't namespaced. So, while WebGL 1.0 is similar to GLES 2.0 which is similar to OpenGL 3.1... They do differ, and the version numbers are meaningless when mixed into the same context. Also fun is how WebGL 2.0 is kind of like GLES 3.0 which is in line with OpenGL 4.ish, but at least we're still a ways away from seeing that supported by most browsers.
  
  
  
  • A similar issue exists for GLSL version numbers. GLSL ES 1.0 is kind of like GLSL 1.2 but not, and the version numbers aren't that comparable.
  
  
• Capability detection doesn't quite work since GLES/WebGL use different names. For example OES_vertex_array_object

[kvark]

Thanks @AerialX ! We\ll work on it.

[AerialX]

@kvark Here's a few more...

• glTexImage2D's format and internalFormat parameters must be the same. Firefox seems okay without enforcing this, but Chromium doesn't like it.
• Fancy texture things like GL_TEXTURE_WRAP_R, GL_TEXTURE_LOD_BIAS, GL_TEXTURE_COMPARE_MODE (and >2D textures in general) don't exist. I believe they're in GLES3/WebGL2 though, and some features may be available as extensions.
• This nasty issue. Unrelated to gfx-rs, but it came up a lot because gfx-rs tends to use best-fit types for values and thus has a lot of unaligned struct members with enums following them. Easiest ugly workaround was to replace all u8 types with u32 in most of the rendering-state-related data structs.

Also, a mini progress demo!

[kvark]

@AerialX Thanks for the update, this is awesome!

[jeffparsons]

Relevant update on Rust's Emscripten support in general: https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and-emscripten/7627

[grtlr]

Since quite some time has passed since the last comment in this issue, I was wondering what is the current situation regarding Emscripten support? Even though it looks like WebGPU is on the horizon, it probably still requires quite some time to be actually ready.

It would be awesome to be able to run gfx-rs programs in the browser as well. Setting up SDL2 with Rust and Emscripten in the browser is straightforward, following this guide. However, I do not know what the limitations of this approach are, mainly is there full access to the OpenGL/WebGL capabilities this way?

[kvark]

@grtlr

Since quite some time has passed since the last comment in this issue, I was wondering what is the current situation regarding Emscripten support?

I took a bite at Emscripten+WASM the other day - https://github.com/kvark/wasm-triangle
Basically, glutin is ready for some WebGL2 stuff, and nothing is blocking this feature from being implemented. Help is still wanted though :)

Even though it looks like WebGPU is on the horizon, it probably still requires quite some time to be actually ready.

We are working within the WebGPU W3C group, and we have a Servo-based prototype.

[kvark]

triaged: leaving open in case someone gets motivated enough to polish the support and get more examples running

[GabrielMajeri]

The quad example seems to work with the native wasm32 target, so I'm guessing this has been solved now. We'll also get direct WebGPU support when #3027 gets implemented.