1732049 - Slow animation when using Mapbox GL

Status: REOPENED

(Core :: JavaScript Engine, defect, P3)

Description

[peter]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

I visit https://visgl.github.io/react-map-gl/examples/geojson-animation

You can get the source code here: https://github.com/visgl/react-map-gl

Actual results:

The animation of the circle is very slow on Firefox Desktop: it seems that many frames are skipped or somehow looks very laggy. In production scenarios this behaviour is very problematic as the animated circle can disappear from the viewport of the map, which is the reason I marked this bug as a defect.

It seems to improve when you make the browser window smaller.

(These "frame skips" also happen sometimes in Firefox mobile. And if you zoom in and out frequently it will be even as worse as in Firefox Desktop.)

Expected results:

It should work as smooth as it works in Chrome.

For reference, see also the bug report in the github repo of this framework: https://github.com/visgl/react-map-gl/issues/1577

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

It's slow on my machine (Ubuntu 20.04), too. That's the case for Firefox Release 92.
With current Firefox Nightly it's smoother, but not as smooth as with Chrome.

Peter: as a quick relief, using Firefox Nightly is perhaps an option.

Comment 3

[peter]

Good to know it is better with Firefox Nightly.

Further information: It seems to occur independently of this visgl react wrapper. See the "pure" mapbox GL JS example here: https://docs.mapbox.com/mapbox-gl-js/example/animate-point-along-line/ the problem does not occur directly there, but click on "edit in codepen", so that the map is bigger (or here: https://codepen.io/pen/?&prefill_data_id=e9c83bb0-a7bf-4388-bf60-07908c68b6d6 ).

Again, for a small map the slowness does not occur.

Comment 4

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

(In reply to peter from comment #3)

Good to know it is better with Firefox Nightly.

Further information: It seems to occur independently of this visgl react wrapper.

Thanks.

See the "pure" mapbox GL JS example here: https://docs.mapbox.com/mapbox-gl-js/example/animate-point-along-line/ the problem does not occur directly there, but click on "edit in codepen", so that the map is bigger

Codepen doesn't show the map. The console shows a 401 error. At least on my machine.

(or here: https://codepen.io/pen/?&prefill_data_id=e9c83bb0-a7bf-4388-bf60-07908c68b6d6 ).

That link doesn't work. Presumably, it worked only temporary.

Again, for a small map the slowness does not occur.

Comment 5

[peter]

Sorry, it seems this was indeed only temporary. I've signed up and saved the example: https://codepen.io/peterla/pen/Pojgeow

With this I can open it in firefox desktop and mobile and also in chrome. Does it work for you?

I can see the same problems documented above (the lag on desktop which gets worse when the window is increased. And the lag exists on mobile too if heavily zooming). I.e. it is also an issue that occurs for mapbox on firefox. Unrelated to react or the visgl wrapper.

Could it be related to this canvas issue? https://bugzilla.mozilla.org/show_bug.cgi?id=890289
http://jsfiddle.net/4qher/2/ - This issue is indeed now mostly fine on chrome but still shows lagging in firefox. (I get an initial jump that I do not mean)

See https://github.com/mapbox/mapbox-gl-js/issues/8614#issuecomment-524043980

Comment 6

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

:dholbert: could you please help triaging this? It's an area of Gecko-code I'm unfamiliar with and you're the triage owner.

Comment 7

[Daniel Holbert [:dholbert]]

It's currently classified as Layout, but I think that's a mistake (just the bot taking a guess in comment 1). There's no CSS/layout work going on here; all of the animation in the testcase here is done inside of a canvas.

I captured a performance profile (good first step when looking at responsiveness bugs), to see what the issues might be and where might be a better place to classify this:
https://share.firefox.dev/3Albqn4

(This was viewing https://visgl.github.io/react-map-gl/examples/geojson-animation in a fullscreen Firefox window with a fresh profile)

The animation generally felt jittery during the whole time I was profiling, but there were a couple of particularly-jumpy sections towards the end, which I think correspond to the red bars in the profile.

I'll call out two specific things in this profile:
(1) The main persistent issue: all of the requestAnimationFrame callbacks seem to be pretty long -- they're consistently over 10ms, and some of them are over 20ms. That's sufficient to make us miss our 60fps animation target, and it seems to be why this example never feels especially snappy (on my machine at least). Here's a particularly long one, 28.8ms long: https://share.firefox.dev/2WLK6Rd .
We're spending 90% of that^ time in the JavaScript engine, so I'll tentatively classify this to that bugzilla component.

(2) Occasional longer jank: the red bars at the beginning and end of this section: https://share.firefox.dev/3Biq8wH
These seem to be places where our thread wasn't being scheduled for some reason (i.e. no profiler samples were captured). That's interesting and potentially a separate issue.

Comment 8

[Daniel Holbert [:dholbert]]

For comparison, here's a profile captured in Chrome:
https://share.firefox.dev/3Bk8jNx

In the Marker Chart view, filtered for "AnimationFrame":
https://share.firefox.dev/3uLy7Qh

I'm guessing that their "FireAnimationFrame" profiler-marker is showing the time spent in requestAnimationFrame callbacks; and those are typically less than 3ms in Chrome, as compared to our 14-30ms requestAnimationFrame callbacks (per issue (1) discussed above).

Comment 9

[Matthew Gaudet (he/him) [:mgaudet]]

Does this fit into the general theme of ReactDOM issues, or something else?

Comment 10

[peter]

It has nothing to do with visgl react wrapper nor with the React framework. See my comment above that this problem also occurs for plain Mapbox JS.

Comment 11

[Iain Ireland [:iain]]

I agree that this doesn't look ReactDOM-related.

Comment 12

[JannikGM]

The root issue isn't the moving circle (which is drawn using WebGL), but the rendering of the entire map which must also be fully redrawn using WebGL on every frame (triggered by some changes in camera position or map state, regardless of the severity).
Aside from the actual drawing, a lot of the standard housekeeping must be done in the mapbox code to load / manage the map data.

Therefore, there are a couple of independent things which could be problematic here (this is all just speculation and by no means a complete list):

• Passing map data from main thread to the webworkers for GeoJSON / map data parsing and back (webworker performance)
• Symbol sorting where the new map data is integrated with other symbol and text on map (JS performance)
• Generation of WebGL resources (this might just be the circle, but it can potentially include other things, too; WebGL performance)
• Rendering of all WebGL resources (again: this isn't just the circle, but rendering starts from a blank canvas on each frame; WebGL performance)
• Compositing of the large WebGL canvas (compositing performance)
• ...

While Firefox performance is considerably worse than Chrome, there's probably no single bug here, but general design differences which lead to slowness in different areas, each contributing to the performance issue.
So, for debugging, it probably makes more sense to profile the mapbox renderer (to find bottlenecks in mapbox), rather than Firefox itself.

Likewise, I'm owner of an issue on maplibre, a mapbox fork which also discusses slowness: https://github.com/maplibre/maplibre-gl-js/issues/96 - so even if Firefox improves, there's much work left to do, to improve mapbox / maplibre performance in general (regardless of the used browser).

Comment 13

[Mayank Bansal]

If I open the codepen (https://codepen.io/peterla/full/Pojgeow) in full page, set zoom to 30%, and set DPI=1, then the animation is janky in Nightly. Chrome is quite smooth.

Nightly: https://share.firefox.dev/48jSTII
Chrome: https://share.firefox.dev/3OJIfEp