The document says DataTexture can receive an ArrayBuffer as argument to construct a new DataTexture.
In fact, three.js will not transfer the ArrayBuffer you passed to an ArrayBufferView ( like a TypedArray) according to its TextureDataType, instead three.js will send directly the ArrayBuffer it self to gl.textImage2D, so an error will be thrown: 'parameter 9 is not of type ‘ArrayBufferView’.
try this codepen: https://codepen.io/hjlld/pen/qzmMoN?editors=0010
Use just data instead data.buffer.
it’s not helpful, either the document is wrong or it is a bug.
It’s a good catch. 
You’re right, this is a bug, could you submit a bug report on github? 
I’m not sure how this is an issue, DataTexture always used a typed view, there is no automatic conversion of a buffer back to a view, the final api call texImage2D requires a view anyway, it rather appears to be a mistake in the docs three.js docs
The data argument must be an ArrayBuffer or a typed array view
It is a mistake in the docs. A separate bug report is not needed if you directly make a PR with the fix. The solution is to alter the first sentence into:
The data argument must be a typed array view.
I don’t think so, because DataTexture.d.ts says you can use ArrayBuffer to construct a DataTexture.
So which is the original design purpose?
That is just adapted from the docs then.
I think it’s a difference in terminology, a bug can be in the code or in the docs. A mistake, an unintended result.
Personally I think an ArrayBuffer makes more sense, since other required input arguments already contain enough information to figure out which typed array it should represent, but hey, I’m cool with either way, as long as there’s a consistency between docs and the code.
The WebGL call texImage2D requires a view, so passing the ArrayBuffer of a view just to reconstruct a view again wouldn’t make sense like in the pen of the OP, it could be added though, for those cases you got a plain ArrayBuffer.
got it, thank you!