len value for Delaunator constructor

[Glidias]

What do you think of a len read limit, so the input array buffer doesn't need to resize itself all the time?

[mourner]

What do you mean? The input typed array isn't mutated at all, and not resized anywhere in Delaunator.

[Glidias]

It isn't resized anywhere in Delaunator. But from end user perseective, if different point soup inputs of different sizes are applied each time... then Delaunator constructor must accept a different array each time since the array length is likely going to be different. If it was possible to accept the same array, but have an enforced read length limit that can be set accordingly like:

constructor(coords, nLen) {
        const n = nLen !== undefined ? nLen : coords.length >> 1;

..so that the same coords reference can be supplied each time, but with different values in place.

Also possible to perhaps not need to reinstantaite, but recall a mutative function with a settable read len property. So, mutate the same array data, then apply read len to cap the read limit according to the varying input sizes it might refer to frame.

But i guess most of your (visual) examples involve 1 delaunator per point soup (of fixed size). I guess i'd just create my own version that suits my use case best, since it's a simple utility anyway. My use case may involve using delanator multiple times per frame. (1 triangulation per object , with potentially hundreds of objects processed each frame with a a single point soup array of changing length). But as it stands now though, it's pretty optimized already and it's one of those yagni low priority things that i'd only consider later.

[mourner]

@Glidias oh, I see what you mean. We could expand the API with len or even start, length arguments, but I think a better approach to suggest is simply using subarray on the original data array. It doesn't do memory copy but is treated as a new typed array object.