SVG overlay using on("move") and project() out of sync in IE/Edge/Safari

[joedjc]

I'm trying to use an SVG overlay like this https://bl.ocks.org/shimizu/5f4cee0fddc7a64b55a9 or this http://bl.ocks.org/enjalot/0d87f32a1ccb9a720d29ba74142ba365.

I use a map.on("move") event to call a function which updates the location of the SVG elements, together with map.project() to get the on screen co-ordinates (similar to the first example - except without hiding the SVG graphics when moving).

In Chrome and Firefox this works well with the SVG graphics appearing seamlessly with mapbox, but in IE11, Edge and to some extent Safari there is a significant lag between the mouse move and the SVG features being updated.

Possibly this is related to this issue: #4681 because I see similar behaviour with markers in those browsers. Not sure if that PR is being progressed?

Example in Edge:

[anandthakker]

Hi @joedjc, thanks for the report. I believe this is a different issue from #4681.

It's interesting that, in the GIF above, it looks like it's the map lagging behind the SVG, not the other way around. @joedjc how does the map's framerate look for you in Edge if you disable the move handler and just pan without the SVG layer being updated?

[joedjc]

Hi @anandthakker thanks for looking into it.

I think you might be onto something there...the SVG does indeed move before the map as though it fires the move event without checking that the map has caught up...or assumes the map can update at the same speed?

I'm sure you're right but the behaviour does look suspiciously similar with markers (e.g. #5360).

I tried testing a few things:

• In all browsers if I have a lot of SVG elements the frame rate slows (not surprising). However, in Chrome it still stays in sync (but at a lower frame rate) whereas the other browsers display the lag.
• It's noticeable in IE11/Edge even with just a small number of SVG features (which is where i'm having a problem). It's visible in Safari but less noticeable...I guess it corrects itself quite quickly.
• If I turn off the move hander, the performance is still quite slow in IE11/Edge with a lot of SVG shapes but is quick in other browsers.

Not sure what to conclude from that...but i'd be interested to know if the move handler is supposed to fire only once the map has actually moved?

If having SVG elements on the page just isn't feasible I guess I could try a canvas overlay instead...might be more efficient although i'm seeing similar behaviour in this example: http://bl.ocks.org/enjalot/cef62e519f94916f62e851d378cee043

Something else I noticed is that, even in Chrome, if you use the zoom controls you can see some similar sync problems as it zooms in/out.

[anandthakker]

We might have found the (or an) underlying issue here: the DragPan handler updates the camera directly and fires a move event. Updates to the DOM that happen in move listeners happen synchronously, but the map renderer doesn't update until the next animation frame.

[joedjc]

@anandthakker Ok...I noticed this also affects zooming, rotating and tilting the map not just panning. Things like double clicking the map to zoom or pressing the compass to reset the map bearing also display this behaviour.

[anandthakker]

Ok...I noticed this also affects zooming, rotating and tilting the map not just panning. Things like double clicking the map to zoom or pressing the compass to reset the map bearing also display this behaviour.

The zooming/rotating/panning are consistent with the above diagnosis, but not the double-click zoom or compass reset -- @joedjc any chance you could post a quick video / live example that exhibits this behavior in those cases?

[joedjc]

I've tried to capture it here - the red boxes are an svg overlay. I am actually using the zoom control buttons which effectively does the same animation as a double click. This is in Safari and running v0.42.2. It's generally more pronounced if the map is full screen. I actually see the lag when using the zoom controls in Chrome (which is generally ok in other cases).

[anandthakker]

#6005 attempts a fix for the drag pan/rotate/zoom cases of this behavior, and should be available in the next release (0.44).

Let's keep this issue closed, as long as those cases are indeed fixed. @joedjc if the zoom de-sync is still an issue on master, would you mind creating a new issue for it?

[joedjc]

@anandthakker I checked on the master and this is looking good for me in all browsers - thank you very much! Only small thing is I find zooming using the trackpad on a mac in Safari still displays a bit of a lag. Doesn't appear using the zoom controls or zooming using a mouse wheel.

[jfirebaugh]

The underlying cause of the desynchronization here is that Safari and IE/Edge are non-spec compliant in running requestAnimationFrame callbacks after the next recalc/layout/paint, rather than before. We'll keep our workaround in place, of course -- just wanted to make a note of that.

• https://bugs.webkit.org/show_bug.cgi?id=177484
• https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/15469349/

[Nagesh-Chandan]

@joedj: "I've tried to capture it here - the red boxes are an svg overlay"
How are you loading the svg file using Source and Layer Or as an Annotation?
can you please provide the code snippet for that, I'm trying this for last two days

Thanks