Design: Pass C++ Array to WebGL Without Copying
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.
aaabbbcccddd00001111
All 3 comments
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).
Macil
on 18 Dec 2019
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.)
kripken
on 18 Dec 2019
Seems that concern was answered, so closing. Please reopen if otherwise.
binji
on 14 Jan 2020
Related issues
frehberg
·
6Comments
arunetm
·
7Comments
jfbastien
·
6Comments
void4
·
5Comments
JimmyVV
·
4Comments
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::vectorthat 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.)