remove point-feature

[jfirebaugh]

The use of point-feature and { x, y } objects seems out of place in such a low-level library. Can we switch to [x, y] coordinates for 2.0?

[mourner]

Two reasons to keep it:

• {x, y} is more performant and takes less memory (apparently V8 reserves more than 2 items for each coordinate internally)
• we need the point abstraction in GL JS, and returning [x, y] would force us to add a conversion step in GL JS, along with GC churn

If you view the library separately from GL JS though, it's indeed weird to have a point type. One thing I considered doing is accepting a point factory in the VT constructor (defaulting to (x, y) => [x, y]), which may be best of both worlds.

[jfirebaugh]

I'm assuming we'd convert gl-js to use [x, y] internally, and use the Point type only for things like cursor coordinates (if even that).

[mourner]

My first point about performance is still valid, and we do a huge ton of coordinate math throughout the code, so rewriting everything for [x, y] and static point arithmetic functions would take a big effort.

[jfirebaugh]

Profiling issues like mapbox/mapbox-gl-js#5208, the GC pressure from allocating lots of temporary arrays and tiny objects is substantial.

I would like to explore an alternate API for v2 based on either ES6 generators or passing in a function to be called for each geometry element (each ring and point). ES6 generators would be more ergonomic, but a callback approach would be more compatible with legacy browsers (IE11) and also avoid the overhead of Point allocations (you could pass x and y as individual parameters).