wasm64: bufferSubData fails after heap grows beyond 4 GB

[jspanchu]

Version of emscripten/emsdk:

|-> $ emcc -v
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.47 (431685f05c67f0424c11473cc16798b9587bb536)
clang version 18.0.0 (https://github.com/llvm/llvm-project 21030b9ab4487d845e29792063f5666d8c4b8e09)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/local/KHQ/jaswant.panchumarti/Documents/code/ansys/vtk-wasm-memory-branch/emsdk/upstream/bin

Error:

Uncaught (in promise) TypeError: Failed to execute 'bufferSubData' on 'WebGL2RenderingContext': parameter 3 is not of type 'ArrayBufferView'.
    at _glBufferSubData (vtkWasmRendererApplication.js:7581:17)

From debugger, it looks like HEAPU8 is a proxy object due to changes introduced by #19737. What is the approach to make the proxy recognizable by bufferSubData?

[jspanchu]

I've found a solution that works, but seems silly. Wonder if we can do better?

-GLctx.bufferSubData(target, offset, HEAPU8, data, data+size);
+GLctx.bufferSubData(target, offset, HEAPU8.subarray(data, data + size), 0, size);

[sbc100]

That seems like a reasonable patch for now (at least until we can remove proxy object, which should be very soon now)

I'm not sure we can make the proxy object appear as a real ArrayBufferView (but I'm not sure about this).

[jspanchu]

Okay! if the proxy objects are going to get removed soon, I've no issue waiting till then.

[sbc100]

Yeah, the proxy objects are a workaround for a chrome bug that IIUC has already been fixed upstream.