[Bug] Huge performance issue with editable layers (EditableGeoJsonLayer)

[andrewk604]

Module

• deck.gl-community/arrow-layers
• deck.gl-community/bing-maps
• deck.gl-community/editable-layers
• deck.gl-community/experimental
• deck.gl-community/graph-layers
• deck.gl-community/layers
• deck.gl-community/react
• deck.gl-community/react-graph-layer

Description

Running the examples/editable-layers/editor example in the deck.gl-community repo shows severe performance degradation during normal editing interactions (pointer move / drag / vertex edit). The UI becomes noticeably laggy, making the editor hard to use.

This looks like an interaction-driven performance issue (likely excessive re-renders and/or too many layer updates per pointer event), but I’m filing it because it happens out-of-the-box on the example.

Attaching a video showing the issue

Deck.gl.Performance.Issues.mp4

Expected Behavior

I expect smooth, non-laggy experience.

Steps to Reproduce

Either run examples/editable-layers/editor in the latest version of the repo, or see this sandbox, which also mimics the same behaviour:

https://codesandbox.io/p/sandbox/deck-gl-demo-f629f5

Environment

• Framework version: deck.gl@9.2.1
• Browser: Arc
• OS: MacOS 15.0 Sequoia

Logs

No response

[chrisgervang]

Is performance poor on your system only when using editable layers, or other deck.gl examples as well?

http://deck.gl/examples/geojson-layer-polygons

http://deck.gl/examples/maplibre

[andrewk604]

Is performance poor on your system only when using editable layers, or other deck.gl examples as well?

http://deck.gl/examples/geojson-layer-polygons

http://deck.gl/examples/maplibre

Only editable layers seem to have poor performance. I also tried it on other MacBooks - like other M1s and the latest M5. The same issue persisted on all devices.

[xinaesthete]

For me (on an M2 Pro), the linked EditableGeoJsonLayer sandbox and http://deck.gl/examples/geojson-layer-polygons are both slow, but the maplibre example is fine.

I did a quick Chrome devtools performance profile, and for geojson-layer-polygons it seems to be spending most of its time in createRenderPipeline, _linkShaders etc. I think this is a known issue with caching of shaders that I've seen mentioned on Slack, but couldn't immediately spot in luma.gl issues (pretty sure it'd be at that level).

For the sandbox, I couldn't see JS methods taking big chunks in the stack, not sure whether this is telling me anything useful with the way the deck app is in an iframe.

[shpakouskaya]

Same issue. Very laggy map as soon as I add/show EditableLayer, even without any polygons/lines on it.

EditableLayer.mov

Environment:
Framework version: "deck.gl": "^9.2.2",
M3 Pro
OS: MacOS 15.3 Sequoia

[xinaesthete]

I think visgl/deck.gl#9863 may relate to this (and potentially fix it, fingers crossed) - may be possible if someone has time to do some testing against development versions of deck etc.

Having said that - if that is indeed relevant, I'm not sure why it'd be particularly relevant to GeoJsonLayers and not others. I haven't looked very deeply into it.

[chrisgervang]

@xinaesthete you got it - this is also what I suspect will help. We've kept it open to allow for testing in the dev environment and could use the communities help here to validate it.

We have a contributing guide with instructions on how to setup a local environment. Then run the examples with yarn start-local to run them.

[felixpalmer]

This should be fixed with deck.gl v9.2.5 which includes visgl/deck.gl#9863 - could you confirm?

[tb-viktor]

This should be fixed with deck.gl v9.2.5 which includes visgl/deck.gl#9863 - could you confirm?

In our experience the performance is indeed better, but with the MapboxOverlay + interleaved mode it is still very jittery when moving the map, especially during the movement transitions at the end when you let go off the mouse button during which the map overshoots slightly and "settles" on a position. In contrast, functions like flyTo are perfectly smooth for some reason. Is there a way to disable these drag animations and just have the map instantly stop where the user stopped dragging?

The EditableGeoJsonLayer in particular makes the performance noticeably worse still, but not as much as before.

Edit:

Also have a reproduction link: https://codesandbox.io/p/devbox/editable-layer-editing-moves-map-forked-hhrwpf?file=%2Fsrc%2FApp.js

[minhemdnv]

I can also confirm that I am having performance issues when using the EditableGeoJsonLayer since deck.gl v9.2.0.
When moving the mouse editing a linestring, I used to get 50-60 FPS. Now it's about 10-15 FPS
Updating to deck.gl v9.2.5 doesn't fix things for me.
It seems like deck.gl v9.1.15 was the last version without these performance issues.

[ibgreen]

FWIW, the perf fix is in luma.gl v9.2.4. installing deck.gl v9.2.5 should pull in that version, but depending on how you manage dependencies it could be worth checking what you are actually running with...

yarn why @luma.gl/core / pnpm why @luma.gl/core etc.

It is possible that there are other perf issues but this should result in a noticeable difference.

[tb-viktor]

FWIW, the perf fix is in luma.gl v9.2.4. installing deck.gl v9.2.5 should pull in that version, but depending on how you manage dependencies it could be worth checking what you are actually running with...

yarn why @luma.gl/core / pnpm why @luma.gl/core etc.

It is possible that there are other perf issues but this should result in a noticeable difference.

In the reproduction that I linked above I am using that deck.gl version, which should then include that luma.gl version with a clean install? It seems to still be a problem there.

[minhemdnv]

I've checked the deck.gl and luma.gl versions simply by entering deck.VERSION and luma.VERSION in the browser console.

In my case at least, I see the following:

• deck.gl v9.1.12 and luma.gl v9.1.9 -> Good performance
• deck.gl v9.2.5 and luma.gl v9.2.5 -> Performance issues

Also, in case it matters, I'm using @deck.gl-community/editable-layers: 9.1.1

I'll try investigating further by profiling these 2 configurations in the browser.