Inconsistent `type` type in `createAttribsFromArrays` about twgl.js

[greggman]

Thanks for the suggestion I think it was a mistake to have `type` be a typedarray constructor ``` { something: { data: [...], type: Uint8Array, }, } ``` vs ``` { something: { data: new Uint8Array[...], }, } ``` not really much point maybe I should just remove that. It's a breaking change though 😢

[bchirlsbiodigital]

I know, breaking changes are distressing. I'm not sure I can think of a way to fix this without it though.

I'm guessing the reason you added it was in case someone provided data as an array or left it out? Whatever the change, I think there needs to be a way to provide the missing info if it can't be inferred.

Might I suggest changing type to usage, since I think that's what's in the WebGL official spec. Also, if you add usage, you can deprecate type for now and make a minor version upgrade instead of having to move to v6 right away.

What do you think?

[greggman]

Maybe I'm mis-understanding what's broken.

The type in AttribInfo is the type parameter of gl.vertexAttribPointer

twgl needs to figure out what AttribInfo.type to use for a given array in createAttribsFromArrays. The cases are

1. you passd in a WebGLBuffer

   In this case you tell it WebGL type via type

2. you passed in a number (so a size you want the buffer to be, no data)

   In this case size is in number of values so it looks at type and expects a typedArray constructor. If not set it assumes Float32Array. From that it sets the AttribInfo.type to the corresponding GL type

3. you passed in a typedarray

   In this case it sets AttribInfo.type to the corresponding GL type

4. you passed in a JavaScript array

   In this case it converts the JavaScript array to a typedarray then goes to case 3.
   Which type of typedarray can be specified by setting type. Otherwise it guesses
   where the guess is either Uint16Array if the name is "indices" else Float32Array

I guess you're bringing up the issue that 1 is different from 2, 3, 4?

One way to make it it would be to make FullArraySpec.type a union of gl type or typedArray constructor. Everywhere it wants a typedArray constuctor in the code, if you pass in a GL type it could look up the corresponding typedArray (cases 2, 3, 4). And via versa, if you pass in a typedArray constructor it would convert it to the corresponding GL type where needed (case 1)

That would not be a breaking change.

Or, I could change case 1 to use a different field. I see the FullArraySpec docs don't list case 1. But it's called type in the docs for gl.vertexAttribArray

Or, I could change type to only ever be a GL type since like I said above, it's kind of silly for case 4, when you can just do data: new TypeIWant(...) for the native array case.

[greggman]

This is one of those things where if I was using someone else's library, I updated to newest, and stuff broke, I'd be upset at the waste of my time. So my gut says to go with making type a union and having either a GL type or a typedArray constructor since that's non-breaking, even if it's less "pure" than adding a new field. It's also argubly better in the sense that you can't make conflicting settings. In other words, if I add usage then you can do this

{
  something: {
    usage: gl.UNSIGNED_BYTE,
    type: Float32Array,  // nonsense as usage is UNSIGNED_BYTE
    data: [...],
  },
}

I supposed that issue already exists

{
  something: {
    data: new Uint8Array([...]),
    type: Float32Array,  // nonsense, though this is ignored since data is a typedarray
  },
}

[bchirlsbiodigital]

My bad: usage is something else. I was distracted. You're right, it's type. Still, unfortunate that it's such an ambiguous name.

I think your assessment looks correct. However, my only issue with using a union is that it might imply that either value would work in any of those four conditions. I think that could be achieved, though, if you inferred the type from either a number, typed array constructor or the typed array itself first, and then within the conditions 1-4, use that type if needed. Make sense?

[greggman]

ok, uploaded v5.1.0

[bchirlsbiodigital]

Awesome. Thank you again for your work. I'll take a look first thing tomorrow.

[bchirlsbiodigital]

works great!