isTypedArray in fromPoints fails with Array of floats

[vorg]

No description provided.

[dmnsgn]

The question is broader, related to pex ecosystem: should we prohibit array of float and force typed arrays (with some utils to expand typed array easily).

[vorg]

with some utils to expand typed array easily

There are solutions like this https://github.com/vorg/geom-builder but then you depend on using geom.count instead of geom.positions.length that might be greately padded with zeros due to last array expansion. I wonder if you could expand the underlaying ArrayBuffer but keep typed arrays tight as they are only views on underlying storage.

[vorg]

should we prohibit array of float

why? how do you build geometries with unknown amount of points?

[vorg]

Also there check should happen once not in a for loop

 for (let i = 0; i < points.length / (isTypedArray ? 3 : 1); i++) {
    if (isTypedArray) {
      includePoint(a, points, i * 3);
    } else {

[vorg]

And num points should be calculated once

[dmnsgn]

The alternative check is ArrayBuffer.isView(points) (with the caveats it also pass new DataView test), as constructor string test is meh. We use that check in couple places (pex-renderer, pex-geom, most of your geom- packages...), should it be in pex-math utils?

Re "if check and precompute point length", benchmark says "it depends":

tl;dr, on v8:

• Comparable speeds for 8 points.
• It is slower for a Float32Array of random points below 10000 points = length 30 000 (which is often our geometry use case) and only gets faster after that amount.

[vorg]

Can we do tests in Safari and FF too?

[vorg]

Another argument is that points.length / (isTypedArray ? 3 : 1) doesn't pass readability test.

[dmnsgn]

Can we do tests in Safari and FF too?

Results are similar in Safari and FF (a bit less precision in browser) but 3 times slower..