Develop 3D game using WebAssembly with WebGL is achievable, if we can pass C++ array to WebGL API without copying the array.
We need to pass array data to WebGLRenderingContext.bufferData() , but it only accepts JavaScript ArrayBuffer or ArrayBufferView . If it accepts C++ array, or if we can create ArrayBufferView without copying array data, then it is solved.
I think the Host bindings, Reference, and/or GC proposals will allow WebAssembly instances to create ArrayBufferViews directly (that could then be passed to WebGL).
This already works today. WebGL functions accept an ArrayBufferView, and it is possible to create such a view on a WebAssembly memory. Basically you create a typed array view on the ArrayBuffer of the Memory, and then do a .subarray
(the emscripten GL bindings do this, for example).
That works if the data is flat in memory. For a C array or a C++ std::vector
that is the case. So sending C++ arrays to WebGL is already how things work today, in most cases.
This does depend on going through JS atm, as in that link from earlier. But no copy is created there! (Skipping the JS would be nice too, as a separate matter, and yes, new specs will allow that, like Interface Types, as @Macil mentioned.)
Seems that concern was answered, so closing. Please reopen if otherwise.
Most helpful comment
This already works today. WebGL functions accept an ArrayBufferView, and it is possible to create such a view on a WebAssembly memory. Basically you create a typed array view on the ArrayBuffer of the Memory, and then do a
.subarray
(the emscripten GL bindings do this, for example).That works if the data is flat in memory. For a C array or a C++
std::vector
that is the case. So sending C++ arrays to WebGL is already how things work today, in most cases.This does depend on going through JS atm, as in that link from earlier. But no copy is created there! (Skipping the JS would be nice too, as a separate matter, and yes, new specs will allow that, like Interface Types, as @Macil mentioned.)