Previously, a lookup object containing start indexes was also used. This allowed us to remove arrays of vertices and properly update the start indexes for remaining coordinate values. In order to provide callers with stable identifiers and to work with arrays of integers alone, we cannot support a remove method. I think this is worth revisiting. Even if the array length cannot be changed in WebGL, we don't need to also impose the restriction outside. Instead, the WebGL renderer could be notified when array sizes change and update itself accordingly. I think there is more value in providing geometries with stable identifiers.
This common structure is used to store vertices for all geometry types. A slight optimization could be made by creating yet another structure to store point vertices - since these don't need to have a counts array (always 1). Creating a new structure would mean saving memory at the expense of more lib code to transport. The coordinate value lookups are not negatively impacted by using the same structure for points and higher order geometries. Since the first change above goes against my instincts, I'm not making this second change (to add another structure for shared point vertices).
Its not clear that we will be able to leverage the Float64Array. It may also be that the overhead of constructing these small arrays negates any benefit of faster access. And for all coordinate arrays, we'll need arrays that grow/shrink.
By having both the constructor and the setComponents checking
a white- and a blacklist for allowed types, we ensure that no
Collections can be added through these methods to the list of
components.
