tc39 / proposal-typedarray-stride Goto Github PK

The following should be explained:

• %TypedArray%.prototype.copyWithin,
• %TypedArray%.prototype.set (both overloads),
• %TypedArray%.prototype.slice,
• %TypedArray%.prototype.subarray
• TypedArray(typedArray) constructor

An important thing to point out is that methods that return new TypedArrays do not preserve stride. The general rule is, if a new buffer is allocated, the new TypedArray has a stride of 1.

It's common for vertex data for WebGL to be interleaved in memory as an array of structs, instead of a struct of arrays. This seems a natural case to take advantage of this proposal's functionality.

However, most types for vertex data are multi-component. This proposal would have this usecase create a view per component.

A fairly standard example of per-vertex data:

struct PerVertex {
    float position[3];
    uint8 color[4];
    float texCoord[2];
};

The proposal would need 3+4+2=9 views to traverse this data, whereas today's standard approach would use two or three views, albeit with more (or at least different) fiddling with offsets to index into the right elements of each view.
The extra views needed make it somewhat onerous to use this proposal in this usecase.

We are concerned about how this might be implemented, and how other vendors are thinking about this. One comment from Anba can be summarized as follows : there is a real performance cost on the JITs, because it changes the address calculation when accessing TypedArrays. Specific optimisations we were using will no longer work due to the stride parameter, and it will no longer be a compile-time constant. Is this an issue other implementers have raised?

In discussion, one way we could see this being addressed is by duplicating the type (Int32Array vs StrideInt32Array). We could also hide this behind a built in library function, with the optimized version underneath. How are other implementers thinking about this problem?

In the simple case, we have tightly packed RGB24 data, with three bytes per pixel. However, Graphics APIs strongly prefer striding width, so that rows of pixels are aligned and padded to multiples of 4, or even 16, bytes. Since there are multiple strides, a single stride is not always enough.

.subarray() is a method to conveniently create views onto the same buffer.

The signature is currently:

typedarray.subarray([begin [,end]])

I think it would be nice to turn this into

typedarray.subarray([begin [,end [, stride]]])

Friendly FYI - At time of writing (commit 2308ded) there is an extraneous close paren on line 35 of the README.

@surma Could you please rename this to proposal-typedarray-stride and transfer it over to the tc39 org?

Instead of stride, would step or interval also appropriate?