The first set geometry is considered the default. As an added bonus, we're back to a single argument constructor. Later, we could allow a schema to be set. This would be done before setting values (calling constructor with no args).
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.
There is a ton of room for optimization here. The vector layer renderer should only render dirty areas and could maintain a cache of rendered canvas tiles. The vector source could have a simple spatial index for features (by tile coord). Need to also discuss how to work with this animation framework (to avoid the excess work while waiting for tiles to load on every other layer).
