perf(raster-tileset): Reduce re-renders of RasterLayer for same per-tile transforms

[kylebarron]

I validated by hand with some console.log statements that this avoids the recreation of the MeshLayer model for the raster layer for each tile, at least in the cog-basic example when toggling the debug layer.

I think the core issue was that with new arrow functions, every change to the tile would cause a new re-render of the RasterLayer.

---

Summary

Compute each tile's forwardTransform / inverseTransform once at tile construction (inside RasterTileset2D.getTileMetadata) and attach them to the tile's TileMetadata. RasterTileLayer._renderSubLayers reads them off the tile instead of recomputing on every render.

Why

Before this change, every call to level.tileTransform(col, row) constructed two fresh arrow functions:

return {
  forwardTransform: (x, y) => affine.apply(tileAffine, x, y),
  inverseTransform: (x, y) => affine.apply(invTileAffine, x, y),
};

RasterTileLayer._renderSubLayers calls this on every render for every visible tile, so the references churned constantly. That instability tripped reprojectionFnsChanged in RasterLayer.updateState, which re-ran _generateMesh, which produced a fresh state.mesh wrapper, which tripped props.mesh !== oldProps.mesh in SimpleMeshLayer.updateState, which destroyed and rebuilt the GPU Model — incurring full shader assembly (assembleGLSLShaderPair, extractShaderUniformBlockFieldNames, etc.) per tile per render.

In a usgs-topo mosaic with ~411 active tile sublayers, this dominated frame time during any layer prop change (e.g. toggling a debug overlay).

Why tile-attached vs. level-cached

Earlier draft of this PR cached tileTransform(col, row) on the level itself. That worked, but the cache had no eviction — entries accumulated for every (col, row) ever queried across the level's lifetime.

Attaching to TileMetadata instead gives correct lifetime semantics for free:

• Tile is constructed by TileLayer → getTileMetadata runs once → transforms computed once
• While the tile is in TileLayer's cache, every render reads the same references off the tile
• When the tile is evicted from TileLayer's cache, the transforms go with it
• Cache size is automatically bounded by TileLayer.maxCacheSize — no separate growth concern

Transforms are also co-located with the (x, y, z) identity that defines them, which is conceptually cleaner.

Verified

In cog-basic with diagnostic logs in place: toggling the debug overlay used to fire RasterLayer._generateMesh and MeshTextureLayer.getShaders once per tile per toggle. With this change, neither fires — only RasterLayer.renderLayers runs, and it's cheap because it just reads stable references off the tile.

Test plan

• Unit test asserts RasterTileset2D.getTileMetadata attaches functioning forwardTransform / inverseTransform to the metadata
• Existing tile-transform behavior tests still pass (94 / 94)
• Visual regression check in usgs-topo-cutline example
• Profile-driven verification in a real mosaic app (usgs-topo)

Supersedes

Replaces #540 (mesh-shape refactor in RasterLayer), which was treating a symptom of this same instability. #540 should be closed in favor of this PR. #541 (shader-assembler memoization) becomes optional defensive caching with this fix in place.

🤖 Generated with Claude Code