Approximate the inputs that Three's WebGL program cache keys on.
This is intentionally broader than the warm-up issue itself: if a material's
compile-time state changes for any reason other than the blend-mode defines
(e.g. colormap enablement, point/line/splat texture-width define, mesh
flat-normal variant), the service must rebuild that source material's keeper
set instead of pinning stale programs forever.
The shader SOURCE enters only as its length, not its text. Both comparisons
this fingerprint feeds stay inside one material lineage — a source material
against its own earlier state, and clones of that source against each other —
and neither can carry different shader text, which every wrapper fixes in its
constructor. Embedding it would make each call concatenate ~25 kB, and
scheduleObject runs on the geometry-commit path and once per affected leaf
per Layers-panel slider event, so that allocation lands squarely on the
interaction path this module exists to keep clear.
Approximate the inputs that Three's WebGL program cache keys on.
This is intentionally broader than the warm-up issue itself: if a material's compile-time state changes for any reason other than the blend-mode defines (e.g. colormap enablement, point/line/splat texture-width define, mesh flat-normal variant), the service must rebuild that source material's keeper set instead of pinning stale programs forever.
The shader SOURCE enters only as its length, not its text. Both comparisons this fingerprint feeds stay inside one material lineage — a source material against its own earlier state, and clones of that source against each other — and neither can carry different shader text, which every wrapper fixes in its constructor. Embedding it would make each call concatenate ~25 kB, and
scheduleObjectruns on the geometry-commit path and once per affected leaf per Layers-panel slider event, so that allocation lands squarely on the interaction path this module exists to keep clear.