Three small verified MeshExtractor.cs fixes from an allocation audit:
- CellStruct clip-map clone guard: the CellStruct polygon-surface path
cloned decoded texture data unconditionally before applying clip-map
transparency, even though the comment above it says "if we got this
from the cache, we need to clone it." The GfxObj path already had the
correct pattern (clone only when textureDataIsCached). Wired the same
textureDataIsCached flag through CellStruct's TryGet/GetOrCreate/
RetainOrUse call sites and gated the clone on it, matching GfxObj
exactly — freshly-decoded arrays (the common case) now skip a
redundant clone + BlockCopy.
- Solid-color texture cache: isSolid surfaces (Base1Solid / NoPos-
stippled polys) allocated a fresh 32x32 RGBA array (4 KiB) on every
polygon, even for repeated colors. Added a MeshExtractor-scoped
ConcurrentDictionary<uint, byte[]> keyed by packed ARGB, bounded by
distinct colors observed (a few hundred at most) rather than call
volume. Traced every downstream consumer of the solid-color array
(clip-map clone-guard, translucency clone-guard, GL upload, pak
serialization) — none currently mutate a solid-color array in place,
since isSolid is mutually exclusive with the texture-decode branch
those guards live in — but wired textureDataIsCached = true at both
call sites anyway so the existing clone-before-mutate machinery
protects the shared array if that ever changes.
- Dropped the redundant .ToList() on both _dats.ResolveId(...) calls:
DatCollectionAdapter.ResolveId already returns a materialized List<T>
typed as IEnumerable; the immediate .OrderByDescending().FirstOrDefault()
enumerates once, so the extra copy was pure waste.
Added SolidColorTextureCacheTests (dat-gated, matching suite convention)
exercising the new cache directly via internal visibility.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
(cherry picked from commit e9f9d7539966cc26343e45d653a751c5d1045810)
