Generating a lot of garbage by using BufferAttribute.updateRange

updateRange parameter of a BufferAttribute is intended to improve performance. I use it in my particle engine. I have been doing some performance testing and found following picture to be pretty standard across my game:

As you can see, about 26% of the garbage alone comes from here: https://github.com/mrdoob/three.js/blob/3a3d2b1e591ced02b5742c6f4dd5d62f457a760c/src/renderers/webgl/WebGLAttributes.js#L66-L88

Why does this happen? Because WebGL1.0 does not allow you to specify offset and length of the source array that you you supply.

Here’s a relevant piece from MDN:

// WebGL1: 
void gl.bufferSubData(target, offset, ArrayBuffer srcData); 
void gl.bufferSubData(target, offset, ArrayBufferView srcData); 

// WebGL2: 
void gl.bufferSubData(target, dstByteOffset, ArrayBufferView srcData, srcOffset, length);

Well, I’m in luck, I do use WebGL2. I’m not sure how to make three.js understand that though, so that we can avoid that needless .subarray call that generates all the garbage currently.

Any thoughts?

[Mugen87]

Would it be acceptable to query the gl context gl.VERSION at WebGLAttributes construction time and set a flag to select the WebGL API form of the call when using bufferSubData?

You may want to use the existing isWebGL2 flag of WebGLCapabilities.

[aardgoose]

Looking at the stats more closely it does look like an overhead of about 90 bytes per array buffer update, so this is probably just the overhead of creating a new ArrayBuffer via subarray() rather than a performance issue with subarray (the issue occurs in FF and Chrome anyway). Which was presumably one of the drivers for the change in the WebGL2 API. There doesn’t appear to be any other way of avoiding the problem.

Would it be acceptable to query the gl context gl.VERSION at WebGLAttributes construction time and set a flag to select the WebGL API form of the call when using bufferSubData?