The API is already different from OpenGL here.Â An ArrayBuffer is nothing like a raw pointer to memory that you'd use in OpenGL.Â The language bindings are also just fundamentally different, and "emulating"
OpenGL here gives an API which is inconsistent both with itself and the
rest of the platform.
(There are other good reasons to try to keep WebGL from deviating unnecessarily from OpenGL, but the language binding level is just inherently different; C and JS are at opposite ends of the language spectrum.)
On Tue, Mar 13, 2012 at 6:20 PM, Ben Vanik <firstname.lastname@example.org>
I suggest that
while modifying the signatures of these methodsÂin future versions that
they be widened to support taking ArrayBuffer as well? For those of us
using XHR/File APIs that return ArrayBuffers or pass around ArrayBuffers
in our code it's often a waste to have to wrap everything in a
Uint8Array/etc before calling these methods - especially when the
implementations don't need the type from the view.
This should be discussed in a separate thread to not derail this discussion, but there's no waste in
creating a Uint8Array from an ArrayBuffer; it's just a thin view and
doesn't create a deep copy.Â (I believe this was discussed on the list recently.)