SpriteAtlas adds all images to the texture

[jfirebaugh]

Prior to 5cdf838, SpriteAtlas added images to the texture atlas on an as-needed basis, as individual images were requested via SpriteAtlas::getIcon. Now it preemptively adds all images to the texture when buildIconMap is called.

Not sure how important the old behavior was. Though, at the very least, buildIconMap should handle the case where the BinPack overflows and getIcon returns a null optional.

cc @ChrisLoer

[mb12]

I've included below an explanation for why it is done this way. @ChrisLoer can you please kindly correct me if my understanding is wrong?

Binpacking of individual spriteatlas elements determines the texel coordinates/UV mapping. Every consumer of texel coordinates for an icon must see the same value. Doing it at the very beginning/together fixes the texel coordinates for all the threads.

Here are examples of different scenarios which would otherwise need synchronization.

1. Symbolbucket needs texel coordinate of each icon as an attribute so that it can coalesce drawing of multiple icons in one 'drawTriangles' call.
   Geometrytile workers in separate threads (separate from renderer thread) must see the same texel coordinate for icons with same name.

2. When rendering fill patterns need to fill the same icon for all the triangles. For these cases texel coordinates can be passed as uniform vec2. The renderer thread also needs to see the same texel coordinates as the worker threads.

If you wish to dynamically resize SpriteAtlas, you must address the following issues.

1. All threads (both worker and renderer) should get the same texel coordinates for an icon.
2. Resizing the SpriteAtlas should not change the position of icons already in use. Otherwise it would invalidate the tex attributes for all vertices uses in symbol buckets.
3. From an opengl perspective u,v coordinates are normalized to [0, 1]. So access to SpriteAtlas.width/height must also be synchronized.

[ChrisLoer]

@mb12 Yeah, those are pretty much the synchronization concerns we have to worry about here -- although GlyphAtlas has all the same concerns and handles incremental updates requested by multiple threads, so we have a pattern we can follow.

@jfirebaugh A lot of the plumbing is actually in place for adding sprites incrementally (we pass dependencies all the way to GeometryTile::getIcons but discard them there). I suspect the extra up-front copying of PremultipliedImages is a pretty small cost, but I hadn't thought through handling overflow. If we're going to support the "more sprites provided than can fit in the SpriteAtlas" case, it seems like we should do it by keeping track of what's requested instead of just dropping sprites based on their order in the data.