We started this conversation on #414.

kainino0x:

This is a little less trivial for setVertexBuffers. E.g. should we allow offsets to be smaller than buffers, and any past the end are treated as 0? Then the default could be []. Or should buffers.length === offsets.length, in which case it would probably make more sense to have two overloads, one with offsets and one without

Another alternative for setVertexBuffers is

setVertexBuffers(u32 startSlot, sequence<GPUBuffer or GPUBufferWithOffset> buffers);
dictionary GPUBufferWithOffset { required GPUBuffer buffer; required u64 offset; }

but this results in annoying-to-type/read code like [{ buffer: b0, offset: o0 }, { buffer: b1, offset: o1 }].

Both this and the current alternative leave something to be desired when it comes to having minimum bindings overhead in the hot path.

Yet another is

setVertexBuffer(u32 slot, GPUBuffer buffer, u64 offset = 0);

I actually think this one is not so bad ergonomically (even though you have to call setVertexBuffer a lot, at least the result code is easy to read). It results in a lot of function calls, though. fwiw, apps also can't cache the two array objects for reuse between frames.

austinEng:

We could also have both so we can support both patterns:

• Preparing the arrays of arguments in advance and then encoding them
• Encoding on the fly without array allocations

kvark:

I'm in favor of individual setVertexBuffer calls. When suggested earlier, the approach was dismissed because of the JS encoding overhead. Now that we have GPURenderBundle, this becomes less of an issue.