5 ms·

As a counterpoint, I've enjoyed building VR on the web using C++ (with WebAssembly/WebGL/WebXR) and not having to touch the DOM or JS, see: https://twitter.com/

by nobbis 5y ago

As a counterpoint, I've enjoyed building VR on the web using C++ (with WebAssembly/WebGL/WebXR) and not having to touch the DOM or JS, see: https://twitter.com/nobbis/status/1425266634982248451 https://twitter.com/nobbis/status/1425266634982248451 Benefits include complete control at frame and pixel level, being cross-platform (same code runs on web, iOS, macOS, Linux), and having access to third-party C/C++ libraries for 3D graphics.

brailsafe 5y ago
This looks really neat
nightski 5y ago
I have not put a lot of time into learning WebAssembly. But isn't WebGL a JavaScript API? Meaning wouldn't you be going from WebAssembly -> JavaScript engine -> WebGL? I was under the impression WebAssembly had no access to the outside world and could only access the relevant JavaScript APIs. But if it is true you can basically do WebAssembly -> native GL then that would be amazing.
- nobbis 5y ago
  You're correct. WebGL does require extra validation compared to native GL, but it's effectively the same API as OpenGL ES 2.0/3.0 and Emscripten handles the translation from C/C++ for you. There's some overhead but it's negligible (assuming you're not making overly redundant API calls.)
  - rock_hard 5y ago
    This is how Figma does it
  - shadowgovt 5y ago
    And that last part is key: for modern high-performance graphics acceleration, the name of the game is "maximum throughput with minimum API interactions." If your data isn't structured for fast rendering, it doesn't matter much what language you're using; they'll all be too slow.
- Jasper_ 5y ago
  emscripten ships a "desktop GL" emulation library [0], which can have quite a bit of overhead. If you want something faster, you can use the native WebGL bindings [1] [0] https://github.com/emscripten-core/emscripten/blob/main/src/library_glemu.js https://github.com/emscripten-core/emscripten/blob/main/src/... [1] https://github.com/emscripten-core/emscripten/blob/main/tests/webgl2.cpp https://github.com/emscripten-core/emscripten/blob/main/test...
  - nobbis 5y ago
    The "native WebGL bindings" still call into JS. Desktop GL emulation is just a layer on top OpenGL ES if, for example, you're still using OpenGL's fixed function pipeline (deprecated 13 years ago.)
- Unit520 5y ago
  WebAssembly has no access to the outside world at the moment, that is correct. It is only able to call (and be called by) JS. A C++ application compiled via Emscripten ships (a fairly large amount) of JS glue code that exposes all relevant Browser APIs like WebGL, Fetch or other HTML5 stuff to the actual WASM program. As others commented, for WebGL an additional API translation is applied. If the source targets OpenGL ES 2 (or 3 for WebGL 2), this step has almost no overhead however.
  - nobbis 5y ago
    Not that large. The JS glue code for the VR web page referenced above is 48 KB, including WebGL, WebXR, Fetch, etc.
- dakom 5y ago
  I wrote an opinionated WebGL wrapper in Rust/WASM here: https://github.com/dakom/awsm-web https://github.com/dakom/awsm-web The idea is that it does more cacheing of things like uniform locations and such so you do very fast in-memory lookups in WASM without hitting the JS Api as much. In the future this will be obsolete since WebGPU has a more optimal API to begin with, and Rust/WASM won't need to go through the JS layer due to "interface types"

by nobbis 5y ago

brailsafe 5y ago

This looks really neat

nightski 5y ago

I have not put a lot of time into learning WebAssembly. But isn't WebGL a JavaScript API? Meaning wouldn't you be going from WebAssembly -> JavaScript engine -> WebGL? I was under the impression WebAssembly had no access to the outside world and could only access the relevant JavaScript APIs. But if it is true you can basically do WebAssembly -> native GL then that would be amazing.

nobbis 5y ago
You're correct. WebGL does require extra validation compared to native GL, but it's effectively the same API as OpenGL ES 2.0/3.0 and Emscripten handles the translation from C/C++ for you. There's some overhead but it's negligible (assuming you're not making overly redundant API calls.)
- rock_hard 5y ago
  This is how Figma does it
- shadowgovt 5y ago
  And that last part is key: for modern high-performance graphics acceleration, the name of the game is "maximum throughput with minimum API interactions." If your data isn't structured for fast rendering, it doesn't matter much what language you're using; they'll all be too slow.
Jasper_ 5y ago
emscripten ships a "desktop GL" emulation library [0], which can have quite a bit of overhead. If you want something faster, you can use the native WebGL bindings [1] [0] https://github.com/emscripten-core/emscripten/blob/main/src/library_glemu.js https://github.com/emscripten-core/emscripten/blob/main/src/... [1] https://github.com/emscripten-core/emscripten/blob/main/tests/webgl2.cpp https://github.com/emscripten-core/emscripten/blob/main/test...
- nobbis 5y ago
  The "native WebGL bindings" still call into JS. Desktop GL emulation is just a layer on top OpenGL ES if, for example, you're still using OpenGL's fixed function pipeline (deprecated 13 years ago.)
Unit520 5y ago
WebAssembly has no access to the outside world at the moment, that is correct. It is only able to call (and be called by) JS. A C++ application compiled via Emscripten ships (a fairly large amount) of JS glue code that exposes all relevant Browser APIs like WebGL, Fetch or other HTML5 stuff to the actual WASM program. As others commented, for WebGL an additional API translation is applied. If the source targets OpenGL ES 2 (or 3 for WebGL 2), this step has almost no overhead however.
- nobbis 5y ago
  Not that large. The JS glue code for the VR web page referenced above is 48 KB, including WebGL, WebXR, Fetch, etc.
dakom 5y ago
I wrote an opinionated WebGL wrapper in Rust/WASM here: https://github.com/dakom/awsm-web https://github.com/dakom/awsm-web The idea is that it does more cacheing of things like uniform locations and such so you do very fast in-memory lookups in WASM without hitting the JS Api as much. In the future this will be obsolete since WebGPU has a more optimal API to begin with, and Rust/WASM won't need to go through the JS layer due to "interface types"