[Bug] CollisionFilterExtension breaking on first render / resize

[ldean43]

Description

On initial render, the CollisionFilterExtension hides all data when using MapboxOverlay with interleaved: false. Data is hidden till the next render.

I have traced this to being caused by a bad collision map in collision-filter-effect.ts. The deck canvas initializes with width: 300, height: 150 leading the initial FBO size to be width: 150, height: 75 after the downscale. After the CSS dynamically resizes the canvas, the FBO does resize but the needsRender flag in _render fails despite the FBO resize.

I have only really tested this using MapboxOverlay, but it seems to be in action on the current CollisionFilterExtension example in the docs.

Screen.Recording.2026-05-23.at.3.35.59.PM.mov

The behavior also seems to happen on canvas resize:

Screen.Recording.2026-05-23.at.3.38.07.PM.mov

I managed to fix this on my project by just adding these few lines to the for loop on collision-filter-effect.ts:85, but I don't know if this is the proper fix:

// Resize framebuffers to match canvas
for (const collisionGroup in channels) {
    const collisionFBO = this.collisionFBOs[collisionGroup];
    const lastWidth = collisionFBO.width;
    const lastHeight = collisionFBO.height;
    const renderInfo = channels[collisionGroup];
    // @ts-expect-error TODO - assuming WebGL context
    const [width, height] = device.canvasContext.getPixelSize();
    collisionFBO.resize({
        width: width / DOWNSCALE,
        height: height / DOWNSCALE
    });
    const fboSizeChanged = lastWidth !== width / DOWNSCALE || lastHeight !== height / DOWNSCALE;
    this._render(renderInfo, {
        effects,
        layerFilter,
        onViewportActive,
        views,
        viewport,
        viewportChanged: viewportChanged || fboSizeChanged
    });
}

Thank you for taking the time to take a look at the issue! I really love the project!

Flavors

• Script tag
• React
• Python/Jupyter notebook
• MapboxOverlay
• GoogleMapsOverlay
• CARTO
• ArcGIS

Expected Behavior

Data items that aren't colliding should be visible on initial render / viewport resize. If they are colliding, the winner should at least be visible.

Steps to Reproduce

Codepen example using MapboxOverlay and ScatterplotLayer. Run the codepen and you'll notice that all scatters are hidden till you pan/zoom the map.

Environment

• Framework version: deck.gl@9.3.1 (company project), deck.gl@9.3.2 (codepen)
• Browser: Chrome Version 148.0.7778.179 (Official Build) (arm64)
• OS: macOS 15.5 (24F74)

Logs

These are some logs I used to help find the issue:

collision-filter-effect.ts:87 [collision] test-isloated canvasSize: (2) [300, 150] fbo: 600 300
collision-filter-effect.ts:147 [collision-render] test-isloated needsRender: true viewportChanged: true fbo: 150 75
collision-filter-effect.ts:87 [collision] test-isloated canvasSize: (2) [1407, 1257] fbo: 150 75
collision-filter-effect.ts:147 [collision-render] test-isloated needsRender: false viewportChanged: undefined fbo: 703.5 628.5

[stevenfazzio]

@ldean43 nice find, and thanks for tracing it so precisely. We ran into this exact bug in DataMapPlot, whose interactive maps draw region labels with a TextLayer + CollisionFilterExtension, and your FBO / needsRender analysis lines up with what we're seeing. Two things that might help:

Regression window (bisection). Same plot, only the deck.gl version swapped (loaded from unpkg), labels checked on first paint with no interaction:

deck.gl	labels on initial render
9.0.41	✅ render
9.1.15	✅ render
9.2.11	❌ all culled until next render
9.3.2	❌ all culled

So it looks like the regression landed in 9.2.x, with 9.1.x the last unaffected line. Might help narrow down the change that caused it.

Not Mapbox/React-specific. We reproduce it with the plain script-tag / standalone Deck flavor (an OrthographicView, no Mapbox, no React, system font), which fits your note that it also shows on the docs example. Same fingerprint: nothing on first paint, then any zoom/pan or a window resize makes every label appear at once.

Minimal standalone repro (save as .html, open in a browser)

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8" />
  <style>html,body{margin:0;height:100%;background:#111}#c{position:absolute;inset:0}</style>
  <script src="https://unpkg.com/deck.gl@latest/dist.min.js"></script>
</head>
<body>
  <div id="c"></div>
  <script>
    const {Deck, OrthographicView, ScatterplotLayer, TextLayer, CollisionFilterExtension} = deck;
    const NAMES = ["Astrophysics","Microbiology","Linguistics","Economics","Geology","Topology",
      "Neuroscience","Robotics","Genomics","Cryptography","Ecology","Optics",
      "Sociology","Hydrology","Phonetics","Immunology"];
    const points = [], labels = []; let k = 0;
    for (let gx = 0; gx < 4; gx++) for (let gy = 0; gy < 4; gy++) {
      const cx = gx * 8, cy = gy * 8;
      labels.push({x: cx, y: cy, text: NAMES[k++]});
      for (let i = 0; i < 24; i++) { const a = i * 2.39996, r = 0.3 * Math.sqrt(i);
        points.push({x: cx + r * Math.cos(a), y: cy + r * Math.sin(a)}); }
    }
    new Deck({
      parent: document.getElementById('c'),
      views: new OrthographicView({}),
      initialViewState: {target: [12, 12, 0], zoom: 5},
      controller: true,
      layers: [
        new ScatterplotLayer({id: 'pts', data: points, getPosition: d => [d.x, d.y],
          getRadius: 2.5, radiusUnits: 'pixels', getFillColor: [110, 150, 210]}),
        new TextLayer({id: 'labels', data: labels, getPosition: d => [d.x, d.y],
          getText: d => d.text, getSize: 18, getColor: [255, 255, 255],
          fontSettings: {sdf: true}, background: true, getBackgroundColor: [0, 0, 0, 170],
          collisionEnabled: true, getCollisionPriority: d => 1,
          collisionTestProps: {sizeScale: 3},
          extensions: [new CollisionFilterExtension()]})
      ]
    });
  </script>
</body>
</html>

Loads deck.gl@latest; labels are missing on first paint and pop in on any zoom or window resize. Change @latest to @9.1 and they render immediately. (Same first-render timing you described, so it's most reliable on a cold load.)

If it'd help to have this tested against a candidate fix, I'm glad to do that.