requestAnimationFrame breaks some synchronization techniques #73

Open
RandomEtc opened this Issue Nov 18, 2011 · 2 comments

Comments

Projects
None yet
2 participants
Contributor

RandomEtc commented Nov 18, 2011

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.

Contributor

tmcw commented Dec 7, 2011

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

Contributor

RandomEtc commented Dec 8, 2011

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment