mapbox / mapbox/mapbox-gl-js

Consecutive filter updates on heatmap layer

Open
#8,268 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

performance :zap:
Dominant language
TypeScript
Stars
12.4k
Forks
2.4k
PR merge metrics
No merged PRs in 30d

Description

(follow up of a conversation with @mikelmaron)

**mapbox-gl-js version**: 0.54

**browser**: Chrome and Firefox latest, macOS

Our current [map](https://globalfishingwatch.org/map/) is a combination of Mapbox GL layers for all non-animated layers, and a custom WebGL renderer for animated heatmaps, which is not performing well enough and is a battery drain (because it’s heavily CPU bound).

### Steps to Trigger Behavior

See below

### Link to Demonstration

On paper, using Mapbox GL heatmap layers would be an ideal solution: not only performance is much better, but also they look way better (and we could remove a huge legacy dependency from our front-end).
The problem is that we can't get this to behave nicely with animation (ie **repeatedly changing a timestamp filter on a layer**). See for yourself: https://codepen.io/nerik8000/pen/rgMdqP?editors=0010

### Expected Behavior

When clicking the start button on the top left, the filter value gets updated at each rAF call to display more or less points depending on a timestamp global value.
When stopping the animation (stopping updates to filter), Mapbox GL should skip any pending update and display the filtered data that matches what the UI expects, which is the last timestamp.

### Actual Behavior

![Kapture 2019-05-21 at 18 10 27](https://user-images.githubusercontent.com/1583415/58112435-cd1cd900-7bf3-11e9-912d-2e49442ff54d.gif)

As you can see in the demo, when clicking the stop button, there's seemingly a queue of rendering updates that get executed one by one. This result in a lag of several seconds between the expected value and what's actually visible in the map.

While I understand the performance implications of filtering that many points (several 10s of 1000s in the demo), there should be a mechanism to allow skipping frames to match as closely as possible whatever values are set from outside. The issue here being that the resulting discrepancy makes any numeric statement displayed outside the map wrong (until the animation's final frame).

Thanks for your help.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the behavior using the linked CodePen and the heatmap layer's repeatedly changing timestamp filter during requestAnimationFrame updates. Compare the final UI timestamp with the rendered map after stopping, then trace the rendering updates involved. Done means pending filter updates no longer leave the map displaying several seconds behind the final timestamp.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.