Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

requestAnimationFrame breaks some synchronization techniques #73

Open
RandomEtc opened this Issue · 2 comments

2 participants

@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
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.