Tiles layer performance issue with layer update.

[peaceshi]

Description

Tiles layer performance issue with layer update.

Expected Behavior

Repro Steps

Github: [source code]（https://github.com/peaceshi/tiles-layer-test/deployments/activity_log?environment=Production） that reproduces the behavior
Vercel: example

Environment

• Framework Version: deck.gl 8.4.17
• Browser Version: Microsoft Edge Chromium
• OS: All

Seems like should not use !== to compare to Objects, because of that will always return ture.
Only primitive type can use it.

deck.gl/modules/react/src/deckgl.js

Line 79 in 38149ae

if (thisRef.lastRenderedViewports !== viewports) {

Then it will be forceUpdate the whole react dom every time when drag or move because it makes a new viewport.
And redraw redraw and redraw frequently that causes a bad performance.

deck.gl/modules/react/src/deckgl.js

Line 83 in 38149ae

thisRef.forceUpdate(v => v + 1);

So that ,when call rebuildViewports(), we set this._viewports.length = 0 maybe a way to fix it.

deck.gl/modules/core/src/lib/view-manager.js

Line 295 in 38149ae

this._viewports = [];

[peaceshi]

#5884

[peaceshi]

https://github.com/peaceshi/deck.gl/issues/1

[peaceshi]

if we use a big cache number, cache.values() will be very huge.

does it have a better way ?

deck.gl/modules/geo-layers/src/tile-layer/tileset-2d.js

Line 315 in 732a1c0

this._tiles = Array.from(this._cache.values())

[Pessimistress]

Rerender is always required when viewports change, however frequently it is. If you don't rerender then you won't see any visual feedback during drag and zoom.

[Pessimistress]

Before jumping to conclusions, I suggest that you describe how you are using the TileLayer, and if possible, the relevant code. It’s very possible that you can simply tweak your own usage pattern to improve performance. If you do think a particular operation in the render cycle is causing the problem, you can use the profiler tool to demonstrate that it's taking significant CPU time.

[peaceshi]

Before jumping to conclusions, I suggest that you describe how you are using the TileLayer, and if possible, the relevant code. It’s very possible that you can simply tweak your own usage pattern to improve performance. If you do think a particular operation in the render cycle is causing the problem, you can use the profiler tool to demonstrate that it's taking significant CPU time.

Sorry for that it was not caused by the viewport array.

Our team member makes this image.
Source code here: https://github.com/peaceshi/tiles-layer-test/blob/2390ba6146e74f65356dc3cb0c7e2cc85eedb73e/src/App.js#L54

After this profiling, fetchTileData has been changed to use async/await.
deck.gl updated to 8.5.0-alpha.10.
Sample site also updated : https://tiles-layer-test.vercel.app/

You can see the fps drop very clearly when drag/move.

[Pessimistress]

I don't see any issue in your performance profile. If you pan to an area that has not been loaded, then the layer is expected to create new sub layers as new tiles come into view. The only optimization I would suggest is to use the extent prop to prevent empty tiles from being created, instead of rendering empty bitmap layers.

I don't see any noticeable lag on your deployed app either. Are you sure it's not a device-specific issue?

[jcready]

One thing that we noticed about the TileLayer is that it attempts to fetch new tiles immediately when the view changes which was causing very slight blocking on the main thread. It wasn't as important for our use case to load tiles as fast as possible so we extended the TileLayer such that the requests for new tiles was essentially debounced. Perhaps there is a better way to do this, but this seemed to work for us:

export DebouncedTileLayer extends TileLayer {
  _updateTileset() {
    if (!this.state.updateTimeout) {
      this.state.updateTimeout = 1;
      super._updateTileset();
    } else {
      clearTimeout(this.state.updateTimeout);
      this.state.updateTimeout = setTimeout(() => super._updateTileset(), 500);
    }
  }
}

The difference is especially noticeable when using something like FlyToInterpolator for viewport transitions or if you have several TileLayer instances.

[jfuehner]

@jcready Thanks for sharing your DebouncedTileLayer. This small change improved our tile layer loading experience as well.