Bucket: Arrays and buffers

[jfirebaugh]

Some refactoring of Bucket to reduce overhead, simplify object structure, improve naming conventions, and make the use of the terms "array" and "buffer" consistent (the latter always referring specifically to an instance of Buffer, not loosely as any kind of data collection).

cc @lucaswoj

[lucaswoj]

Why did you choose to call this vertexArray instead of layoutArray?

Conceptually the paintArrays and layoutArray are both vertex arrays. The distinguishing characteristic is that one contains data from paint properties and the other data from layout properties.

[jfirebaugh]

Makes sense, I'll rename to layoutArray.

[jfirebaugh]

Or how about layoutVertexArray, paintVertexArrays, layoutVertexBuffer, paintVertexBuffers?

[lucaswoj]

That's good too 👍

[lucaswoj]

This is ready to once you've addressed the actionable comments above ^

---

I have a bigger-picture refactoring of Bucket in mind that may be worth pursuing before porting this 😐 architecture to native.

The hierarchy of objects in our data system roughly looks like this:

Tile -> Bucket -> program interface -> array group -> layout and paint arrays

We could simplify by collapsing the hierarchy to:

Tile -> TileLayer

There would be a 1:1 correspondence between TileLayers and calls to drawElements. All information that was previously stored in the object hierarchy would be stored within TileLayer.

class TileLayer {
    programInterface: ...
    layoutArray: ...
    vertexArray: ...
    paintArrays: ...
    ...
}

We could also factor all TileLayer creation logic (i.e. addFeature) out into a new set of TileLayerFactory classes. This functionality is only used within the workers.

[jfirebaugh]

Holding on merge here until post 0.21 release to avoid regression risk.

[lucaswoj]

Ready to 🚢 ?