Significant latency on Windows when drawing shapes from deck8.6/nebula1.x onwards

[danielgormly]

Describe the bug

Significant latency when performing certain actions on Windows 10 & 11 across many machines and at least several browsers (Firefox, Chrome, Edge), from nebula@1+. I have tested personally on a stripped back version with the bare essentials and verified with many customers. My own test machine has a GTX2060, 11th gen i7, 16GB ram & runs Windows 11. My Mac M1 and a few Intel Macs do not seem to have this problem.

Actual Result

• Adding first point of polygon on Windows = 1-2 second on a clean environment (perhaps other Deck layers compound the issue). Browser is also blocked completely).
• Limited testing with other types on Windows (e.g. line) shows smaller but noticeable latency.

Expected Result

• Adding first point of polygon appears to appear instantly, as do other shapes, with no noticeable main thread blocking as they do on a Mac.

Reproduce Steps

Note I am building this with a basic Vite setup. Happy to post repo if convenient.

main.js (minimal repro)

import { Deck } from "@deck.gl/core";
import * as nebula from "@nebula.gl/layers";
import * as editModes from "@nebula.gl/edit-modes";

const INITIAL_VIEW_STATE = {
  latitude: 37.8,
  longitude: -122.45,
  zoom: 15
};

const drawingLayer = new nebula.EditableGeoJsonLayer({
  id: 'geojson-layer',
  data: { type: 'FeatureCollection', features: [] },
  mode: editModes.DrawPolygonMode,
  selectedFeatureIndexes: [],
  onEdit: ({ updatedData }) => {
  }
});

new Deck({
  initialViewState: INITIAL_VIEW_STATE,
  canvas: document.getElementById('canvas'),
  controller: true,
  layers: [
    drawingLayer,
  ]
});

Dependencies with less delay on Windows

"dependencies": {
    "@deck.gl/core": "8.5.10",
    "@deck.gl/geo-layers": "8.5.10",
    "@deck.gl/layers": "8.5.10",
    "@deck.gl/mesh-layers": "8.5.10",
    "@nebula.gl/edit-modes": "0.23.8",
    "@nebula.gl/layers": "0.23.8"
  }

Dependencies with significant delay, also appears to be present in all combinations of later versions of @deck.gl/* + @nebula.gl/* I have tried.

"dependencies": {
    "@deck.gl/core": "8.6.0",
    "@deck.gl/geo-layers": "8.6.0",
    "@deck.gl/layers": "8.6.0",
    "@deck.gl/mesh-layers": "8.6.0",
    "@nebula.gl/edit-modes": "1.0.4",
    "@nebula.gl/layers": "1.0.4"
  }

[ibgreen]

Not sure if this helps, but ff it is just an initial freeze, and perf is good after that...

I have seen issues a couple of years ago where the WebGL shaders could take 1-2 seconds to compile and link on Windows systems where the same operation would take milliseconds on Macs.

Also noting that PathLayer is deck's most complex shader, and that is where the freezes were most pronounced.

Per some discussions with the ANGLE/Chrome folks, the reason was suspected to be some complications in the mapping of WebGL APIs to the underlying Direct3D APIs.

I assumed that this was machine specific, but it sounds like that is a persistent issue.

Some experimentation with the shader showed that this compilation/linking time is quite sensitive to the contents of the shader. Changing a line could drop the time from 2s to 1s.

If that is still the issue, fixing it is a challenge as the deck.gl maintainers are not working on windows machines, so any day-to-day edits to those shaders could regress the compilation performance.

However, it is possible that the issue is made more pronounced by the checking of shader compile and link status - it may trigger a GPU pipeline stall, freezing the browser. You could potentially comment these checks out in your node_modules/@luma.gl/webgl dist and see if that helps:

• https://github.com/visgl/luma.gl/blob/8.5-release/modules/webgl/src/classes/program.js#L341-L352
• https://github.com/visgl/luma.gl/blob/8.5-release/modules/webgl/src/classes/shader.js#L96-L108

If it does, we could make those checks optional via some deck prop or global flag, giving you a path to some relief.

I think there is an async shader compilation extension in WebGL now: , but it would be a little tricky to integrate.

[danielgormly]

Appreciate the detailed response and suggesting some starting points, makes sense that it could be a d3d/gl translation thing. Commenting those blocks ^ didn't have a noticeable effect but we'll take some time early next year to look at everything beyond the surface.