Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setData() and smart diffing #1391

Closed
peterqliu opened this issue Jul 26, 2015 · 4 comments
Closed

setData() and smart diffing #1391

peterqliu opened this issue Jul 26, 2015 · 4 comments

Comments

@peterqliu
Copy link
Contributor

Currently, the only way to bind and update data to layers is via setData. Regardless of how new data differs from the old, this involves a full rerender. The downsides are familiar:

  1. This is slow. Noticeable delay before update happens.

  2. Makes continuity difficult. If we want to show a vehicle marker moving down the street, it involves creating and destroying markers in a repeated fashion, rather than animating one marker to new positions (to be fair, if we made # 1 extremely fast, the two become indistinguishable).

The ideal solution would be able to

  1. Handle atomic changes to source data in a way that's smart and fast, and
  2. Distinguish new "objects" in the data (e.g., new cars on the road), from merely updated states of existing objects (cars that have moved)

The obvious predecessor here is D3's enter/update/exit pattern.

cc/ @kelvinabrokwa @tmcw @jfirebaugh

@tmcw
Copy link
Contributor

tmcw commented Jul 26, 2015

The d3 model is heavily influenced by the SVG/HTML rendering model: it
really should not be the first thought for a system in GL, which has a
fundamentally different approach to data and rendering.

On Saturday, July 25, 2015, Peter Liu notifications@github.com wrote:

Currently, the only way to bind and update data to layers is via setData
https://www.mapbox.com/mapbox-gl-js/api/#geojsonsource/setdata.
Regardless of how new data differs from the old, this involves a full
rerender of the map. The downsides are familiar:

  1. This is slow. Noticeable delay before update happens.
  2. Makes continuity difficult. If we want to show a vehicle marker
    moving down the street, it involves creating and destroying markers in a
    repeated fashion, rather than animating one marker to new positions (though
    if we make 1) fast enough, this becomes moot).

The ideal solution would be able to

  1. Handle atomic changes to source data in a way that's smart and fast, and
  2. Distinguish new "objects" in the data (e.g., new cars on the road),
    from merely updated states of existing objects (cars that have moved)?

The obvious predecessor here is D3's enter/update/exit
http://bost.ocks.org/mike/join/ pattern.

cc/ @kelvinabrokwa https://github.com/kelvinabrokwa @tmcw
https://github.com/tmcw @jfirebaugh https://github.com/jfirebaugh


Reply to this email directly or view it on GitHub
#1391.

@lucaswoj
Copy link
Contributor

If we built a system that would allow us to make incremental changes to the GL buffers (which is possible), we would still have to do an O(n) copy of the entire buffer to the GPU on every change. Let's focus on making GL fast enough to create fresh buffers at a framerate suitable for animation and keep this idea on the back burner.

@jfirebaugh jfirebaugh mentioned this issue Aug 12, 2015
4 tasks
@mourner
Copy link
Member

mourner commented Aug 12, 2015

Also see upstream: mapbox/geojson-vt#26

@lucaswoj
Copy link
Contributor

I don't see this feature fitting into GL JS's API. We should continue trying to make setData faster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants