The quick answer is because “IMemoryRange” is not the WebGL API. The idea is to target the WebGL API more cleanly, with less “additives”
I have partially written a new typed array implementation, which uses abstracts instead of classes for each type, it is twice as fast (in my tests) and could lead to a much lighter implementation for the views.
In this case, you could hold onto your ArrayBuffer, but then construct a new ArrayBufferView based on the subset of the buffer you really want to use, no copying would be done.
If there are other ways to more effectively manage this within the GL API (even if it is only a WebGL 2.x feature, for example) then I’m interested to hear – if there is a newer feature to combat this problem, we might be able to provide a compatibility implementation on HTML5, and streamline it elsewhere. Thank you so much for your input
I think it should be similar, WebGL is mapping to GL on the desktop or GLES on mobile, after all (on the browser).
I feel like optimizing the typed array implementation is critical, then if anything needs to be done to optimize the native wrapper, so be it, but I think the typed arrays are the first stop. I don’t want to handicap performance, but I also want to keep a standard/familiar interface, so that’s why things were aligned closer to the standard WebGL API here
I solve re-allocation problem on native targets. I need upload different chunks of data from another bigger buffer to vbo/ibo a few times per frame, so re-using ArrayBufferView hack is very useful for me on native targets: