Animations of circle layer extremely sluggish in version 1.30

[thunderkid]

I am animating the appearance and disappearance of ~2000 circles over 10 seconds using a data driven circle-layer. In version 1.2.1, this was running fine at ~35fps, with the circles updating continuously. In version 1.3.0 the circles no longer update continuously - they update in batches only about once every 2 seconds, giving a very sluggish/jerky experience. (NB: If you just look at the fps, it's now reporting ~50fps, so by that metric it's faster than before, but that's because it's no longer doing the hard work of actually updating the circles. As soon as you look at the map as opposed to the fps meter, you see how bad the performance is now.)

mapbox-gl-js version: 1.3.0

browser: Chrome 76

Steps to Trigger Behavior

1. Add a data-driven circle layer.
2. Animate the underlying data so that, say, 2000 circles appear randomly with a lifetime of 1 second each, over a 10 second interval.
3. Watch how extremely sluggish it is compared to MapboxGL version 1.2.1.

Expected Behavior

Animation at least as smooth as version 1.2.1.

Actual Behavior

Animation dramatically less smooth than version 1.2.1.

[mourner]

@thunderkid oh no! This is likely because of changes in #8633 and #8673. Can you provide a minimal live (e.g. JSFiddle) test case? That would make it much easier to get to the bottom of this and do a quick fix.

[arindam1993]

@thunderkid I tried to create a reproducible example based on your description. Here are the fiddles:
1.2.1: https://jsfiddle.net/5sg4b3co/
1.3.0: https://jsfiddle.net/sd7rk0hu/
Based on your description, my hunch was that you may be calling map.setData every time you add or remove a point, and in that case 1.3.0 does cause a regression, since it floods queue in the worker.

However, the general best-practice when animating is to call map.setData in a requestAnimationFrame loop, which throttles the map updates to the same rate as which the browser's frame rate. You can still update your data at any frequency you want.
Demo fiddle with workaround:
https://jsfiddle.net/sd7rk0hu/2/

@mourner @asheemmamoowala , not sure if this is a release-blocker, given it might be a bad implementation.

[thunderkid]

@arindam1993
No, I'm not calling map.setData for every point added - my animation loop uses requestAnimationFrame and it's pretty robust. I've double checked this by logging every call of setData, and it's only being called at the browser frame rate.

I'm afraid I can't get your fiddles to tell me much - the last one doesn't load at all.

My animation is a bit more complex than yours. For each event I add a circle with text in the center, and over ~1 second it expands by a factor of ~1.5 and simultaneously fades, then disappears. It looks nice and smooth on v1.2.1, but not on 1.3.0.

It's a fairly complex project so hard for me to produce a small fiddle for it. I was hoping someone else would have something smaller and cleaner for stress testing. I could probably produce a couple of animated gifs to show you what it looks like, but the degradation is pretty bad!

[asheemmamoowala]

@thunderkid animated gifs would be a good start.

Can you say more about how many circles are in your source, and how frequently the events occur that add circles? How many layers are referring to the source, and what is the complexity of the expressions in the layer properties?

[thunderkid]

@asheemmamoowala
So here are a couple of gifs to give you an idea of the degradation:
Here it is with MapboxGL 1.2.1:

And here it is with MapboxGL 1.3.0:

(I noticed that the latter gif is < half the size of the former, which is a striking measure of the information loss!)

In this example I'm adding 1000 circles over a 10 second interval. Each circle expands for 0.5 seconds, then fades for 0.4 seconds. So on average around 100 circles are active at any moment. There are two layers referring to the data source - a text layer which doesn't do much:

    'type': 'symbol',
    'layout': {
        'text-field': '{qcval}',
        'text-size': 11,
    },

and a circle layer which gets the radius and opacity which are dynamically driven by the animation of the data source, updated by requestAnimationFrame. (It also gets the color, which in this example is always just red):

    'type': 'circle',
    'paint': {
        'circle-radius': ['get', 'rad'],
        'circle-color':  ['get', 'color'],
        'circle-opacity': ['get', 'opacity'],
        }
    }

Hope that helps.

[kkaefer]

I've created a similar fiddle based on earthquake data:

• 1.3.0: https://jsfiddle.net/9w2sz8f1/0/
• 1.2.1: https://jsfiddle.net/9w2sz8f1/1/

I've tried this in Firefox 70, Chrome 76, and Safari 12, all on 4-core Macbook 15" running macOS, but was unable to spot any differences. They all get sluggish after a few seconds, but I can't tell that 1.2.1 is less sluggish than 1.3.0. @thunderkid, are you able to share a reduced test case with actual code (like a jsfiddle test page) that exhibits what you're observing?

[thunderkid]

@kkaefer: Thanks! That's a nice clean example and it runs fine on my systems too under 1.3.0. My own code uses React & Mobx and has other non-animating layers so it will take a bit of work to figure out what's interfering with the animation, but I'll try to build a simple test case.

[sunaviation]

I fully agree with @thunderkid that 1.2.1 is less sluggish than 1.3.0

Environment

MacOS Catalina 10.15 Beta

browsers:
Chrome 76.0.3809.132
Safari 13.0 (15608.2.5)

mapbox-gl-js version:
1.3.0 compared with 1.2.1

latest turf version:
5.1.6

jQuery:
3.4.1

Steps to Trigger Behavior

parse large geojson files

$.getJSON('assets/geos/airports.geojson', function (data) {     // 52.875 objects
$.getJSON('assets/geos/navaids.geojson', function (data) {      // 11.118 objects

points = geoJSONAdNa;

while moving the mouse @turf/nearest-point is using: takes a reference point and a FeatureCollection of Features with Point geometries and returns the point from the FeatureCollection closest to the reference.
Once the nearesat point has been found, parse the array of coordinates and text, draw a circle on the parsed coord position, also draw a line between nearest position and the mouse pointer.

    targetPoint = turf.point([e.lngLat.lng, e.lngLat.lat]);
    points = geoJSONAdNa;
    nearest = turf.nearestPoint(targetPoint, points);
    map.getSource("ancorcoord").setData(nearest);
    map.getSource("ancorcoorddest").setData(nearest);
    snappedcurrent = [nearest.geometry.coordinates,targetPoint.geometry.coordinates];
    map.getSource("snappedlinecurrent").setData(snappedLinecurrent());

Actual Behavior

I've created two versions based on my project on clpa.tunayschuster.com.
same code, only mapboxGL version replaced 1.2.1 <-> 1.3.0

1.2.1: https://clpa.tunayschuster.com/performance-test-mapboxgl_1.2.1.html
1.3.0: https://clpa.tunayschuster.com/performance-test-mapboxgl_1.3.0.html

Behavior less smooth than version 1.2.1.