Instead of going into an unnecessary animation loop, we can simply wait to be notified when tiles load.
The WebGL renderer still sets frameState.animate true, but I think this too should be unnecessary (full page example works without it, side-by-side example shows it cannot yet be removed).
Instead of keeping track of wanted tile ranges, we can instead track wanted tiles individually. This provides enough for the map to know how to prioritize tiles and should be more efficient (no extra calls to extend tile ranges or check for tile containment within a range).
* Tiles are now cut out of the sketch renderer in a separate
pass. This ensures that point features at tile borders appear
at both sides of the border. However, if such features get
added in a later tileRange rendering pass, tiles from a
previous rendering pass will still not have that feature.
* The tile canvas is only created once, and cloneNode(false) is
used to get a canvas for a new tile.
It looks like this approach will work well for panning (as anticipated). For animated zooming, it is not going to work as is. It looks like the canvas tile generation is too much for this type of animation loop. Though there are clearly still areas for optimization:
* Don't create new tiles while animating between zoom levels. Using existing tiles only while animating should bring a significant performance gain.
* Simple spatial index for tiles - each tile coord in the matrix could have a feature lookup object (keyed by id). This needs to account for rendered dimension (as witnessed by the point being cut by a tile). Given that the current example uses only three features, adding the spatial index should only be a minor improvement.
* Reuse a fixed set of canvas tiles that are generated at construction (and increased/decreased with view size changes).
* If a fixed set of tiles is not used, at least new ones could be cloned from existing ones (minor).
* Do some profiling to look for more ideas.
In addition, world-wrapping needs addressed. I don't think this renderer is the right (or at least the only) place to address this. And the cache of tiles needs to be managed for real. But hey, at least we've got a working tiled vector renderer now.
I think it's complicating things at this point to deal with this. Unfortunately, it's not proper dateline wrapping as is (only arbitrary tile range extent wrapping).
With the frameState stuff the map renderer need not listen to view changes. The map renderer receives orders from the map. These orders are renderFrame_ calls with frameState objects representing the current state.
What we want in the end is vector tiles repeated just as raster
tiles. This change only avoids repeated tiles with the same
content being rendered and stored in the cache.
Éric Lemoine
Tim Schaub
Tom Payne
ahocevar
Éric Lemoine