Previously, the map renderer would listen for layers being added and
removed from the layers collection, and would create and remove layer
renderers in response to these events.
With this change, layer renderers are only created or removed when
renderFrame is called, which leads to somewhat simpler code.
We still need to listen to changes to the layers collection, but now
these only trigger a new render.
This new approach also has an advantage when layers change order.
Swapping the order of two layers involves removing one and re-inserting
it elsewhere. With the old approach, this would cause the deletion and
re-creation of the layer renderer. With this new approach, the layer
renderer is preserved.
getTile and the tileUrlFunc are functions of the source, so they do need to be passed the tile grid. The tile source knows its tile grid, and can get the projection's tile grid if it doesn't have a tile grid.
This massively reduces the number of temporary ol.TileCoord objects.
Previously an ol.TileCoord object was generated for every potentially
visible tile at the current zoom level and lower, every frame. This
commit eliminates all of those. Now new ol.TileCoord objects are only
allocated when a new tile is created.
Rendering vector tiles with mixed geometry types does not work
as expected, because the tile is created without the geometries
that need another rendering pass because of missing icons. This
was discovered by @bartvde when working on the KML parser, where
mixed geometry types are common.
This change fixes the issue by breaking out from rendering
entirely when renderFeaturesByGeometryType returns a deferred
state. In addition, there was a related bug because icons are
added to the cache regardless of its loaded state. This is also
fixed now.
The previous logic assumed that if there were any tiles to render, the dirty state should be false. The correct logic is to say that if we don't render during animation, dirty is true.
The color names are more intuitive. And if we want to support pattern strokes or fills, we'll need additional proerties to represent other pattern properties.
