perf(raster-layer): avoid re-compiling shader Model as much as possible

[kylebarron]

It's very important to reduce shader recompiles as much as possible. Changing a pixel filter slider should be nearly instant; it should just be updating the uniforms to pass into the existing GPU pipeline.

Previously we were re-compiling the shader model on every render, because the mesh instance was not passing instance equality.

Significant performance improvement in the NAIP mosaic pixel filter slider:

Before:

Screen.Recording.2026-05-14.at.1.06.47.PM.mov

After:

Screen.Recording.2026-05-14.at.1.14.07.PM.mov

---

Summary

Two-part fix that lets RasterLayer/MeshTextureLayer reuse the same luma.gl Model (and its compiled shader) across renders, while still rebuilding it the rare times the shader source actually has to change.

1. RasterLayer — store the full {indices, attributes} mesh wrapper in state.mesh and pass it directly to MeshTextureLayer, so the reference stays stable across renders.
2. MeshTextureLayer — override updateState to force a Model rebuild when the renderPipeline module list changes (which the upstream SimpleMeshLayer has no way to know about, since it only checks mesh and extensions).

Why

SimpleMeshLayer.updateState rebuilds its Model whenever props.mesh !== oldProps.mesh (reference equality check). Before this change, RasterLayer.renderLayers() built a fresh wrapper object on every render — so every tile sublayer destroyed and recreated its Model every frame, running full assembleGLSLShaderPair and vertex-buffer setup per tile per frame.

In the naip-mosaic example, moving the NDVI range slider dropped a single redraw frame to ~120ms in profiles, with warnIfGLSLUniformBlocksAreNotStd140 (11.5ms) and extractShaderUniformBlockFieldNames (9.0ms) dominating self-time — both functions only run inside assembleGLSLShaderPair.

Relation to #543

#543 fixed an upstream churn source (tileTransform returning fresh arrow functions every call) and ended the constant _generateMesh re-runs in RasterLayer. That was sufficient for scenarios where the changing prop didn't propagate to RasterLayer's renderPipeline (e.g. the debug overlay toggle tested there). It's not sufficient when the changing prop is renderPipeline itself — which is the common case for any interactive uniform (sliders, color pickers, etc.). The mesh wrapper is still rebuilt in renderLayers() for those, and the Model still churns. This PR closes that gap.

Why the mesh-only fix wasn't enough

The first iteration of this PR (18f32ca) only stabilized the mesh reference. That broke render-mode switching: with the Model preserved, the shader source froze at whatever renderPipeline was active when the Model was first built. Switching renderMode: trueColor → ndvi in the naip-mosaic example produced new modules in renderPipeline, but the GPU silently kept running the original RGB shader.

The second commit fixes this in MeshTextureLayer.updateState: it compares old vs. new module identities (plus image presence) and forces a single Model rebuild when they differ. Prop-only changes within the same module list — the slider case — skip the rebuild and update uniforms via shaderInputs.setProps in draw().

Verified

In the naip-mosaic example:

• NDVI slider (same module list, different uniform values): no Model rebuilds. Frame cost drops to roughly uniform-update + redraw. Slider feels instantaneous.
• Render-mode switch (different module list): one Model rebuild per visible tile, at the moment of the switch. Imagery updates correctly. No per-frame cost after.
• Initial tile load: one Model build per tile, as before.

Test plan

• Unit test asserts state.mesh reference is stable across renders when mesh-affecting props haven't changed (0d21f83)
• Typecheck + 96 existing unit tests passing
• End-to-end functional check in naip-mosaic: slider and mode-switch both work
• Profile-driven verification in naip-mosaic: ~120ms frame → instant slider
• Add unit test for MeshTextureLayer module-list-change rebuild path
• Verify no visual regression in usgs-topo-cutline example
• Investigate the DECKGL_FILTER_COLOR shader compile error previously seen in usgs-topo (likely orthogonal — that error was bisected as preexisting in initial testing of this PR)

🤖 Generated with Claude Code

[kylebarron]

The root cause was found and resolved in #543 It turns out this is a separate and also important root cause