requestAnimationFrame breaks some synchronization techniques

[RandomEtc]

The twomaps example is unstable because it can't lock one map while updating the other now that we're using requestAnimationFrame which fires with a delay. We could implement a simple catch-all change event (possibly instead of panned, zoomed etc) to mitigate this.

[tmcw]

Hmm, any browser in particular you're seeing this on? The example looks pretty smooth to me.

[RandomEtc]

Yeah it's OK now. It's fixed by using the centered, panned and zoomed callbacks instead of drawn.

Before requestAnimationFrame entered the scene everything was completely synchronous so that after any calls that modified coordinate you would know that the draw function had been called and all tiles would be in the correct place. Now there's an unknown delay while we wait for draw() so the drawn callback is fired after calls that modify the center coordinate. That's what caused the issue with the twomaps demo.

We're not completely thorough with the usage of zoomed, panned, centered, extentset etc which is why I tended to hook my examples up with drawn. In this case the other events are good enough but for a full overlay class they might not be - hence the proposal for a generic changed event instead.

...

Blah, blah...

Longer term I think splitting draw() into update() and draw() and firing separate updated and drawn callbacks would be cleaner. That way update() would keep the coordinate in check with enforceLimits() and potentially start requesting new tiles, and an updated event could be fired synchronously whenever the map view was changed. The drawn callback would allow you to chain overlay redraw onto the map's own draw event to guarantee that overlays are locked in place. The draw() function would be the only thing to actually modify the DOM and that would be its only responsibility. In future canvas or webgl layers it would be responsible for repainting. Big change in the short term though...