Renderer buffer pool

[ori-sky]

The OpenGL renderer should keep a pool of vertex buffers of appropriate sizes, and incoming primitives (detailed in #13) should be managed and uploaded intelligently to an appropriate buffer in order to maximize performance.

I'm still unclear on how exactly primitives should be managed, as there needs to be an easy, efficient way to remove a set of primitives at a later time. More discussion should follow.

This issue depends on #13.

[ori-sky]

Perhaps primitives should be submitted not as an infinite sequence of primitives but rather as an infinite sequence of finite sequences of primitives.

This means that primitives would be submitted as ranges and not individually, implicitly preserving information about the ranges/neighbours of each primitive. This information would therefore allow the renderer to return (? how?) a unique ID to each range submitted, making it very easy to remove that range from the renderer.

[ori-sky]

Looking into this issue a bit more now that the renderer message queue exists.

There needs to be a way to keep track of which vertex buffer each ID is in, as well as what its range in the buffer is. My initial thought is to store a HashMap of ID => (BufferID, Range) or something similar to this. Using a HashMap will allow arbitrary deletion of IDs without affecting the others, unlike a Vector, and in fact this is possibly something that should be done for VectorStorage as currently I'm unsure how arbitrary data could even be deleted.

[ori-sky]

An interesting thing I just realised is that storing VectorStorage elements in a HashMap instead of a Vector (we need to rename it..) will allow us to use a custom integer key type for lookups.

A newtype of Integer for example would incur no additional overhead and prevent collisions with regular integer keys.