SdfShaderForge

The one process-wide consumer of rhi::PipelineForge for SDF shaders.

In the namespace construct::shader. Declared in src/libs/libconstruct/construct/shader/SdfShaderForge.hpp.

Detailed description

construct-scene-evaluator §EV-A6.2. Every shader build in the process — the inline layer's, the worker layer's, the thumbnails', the material preview's — is a request here: a ShaderBuildRecipe for a SITE (the forge's supersede group: "layer:<id>:geometry", say). The forge dedupes by content key, keeps a byte-bounded cache of built artifacts, drops a site's older queued request when a newer one arrives, and never caches a failure (EV-D15). The build itself runs `compileSdfFragment` per stage, OFF the calling thread.

Where the build runs

The executor is one of two, chosen by the host: - With setBatchQueue(): each job becomes a `construct/shader_forge` batch job that ShaderBuildWorker (Pooled, compileThreadPriority()) runs on the shared batch pool — so the GUI's progress chip shows one entry per pending build (§EV-A6.6) and "how much runs at once" has one answer (batch-orchestration BO-13 to BO-15). The worker calls runQueuedJob(). - Without one (a test, a headless tool): a private pool at the compile priority, so a consumer with no queue still never compiles on its own thread.

How a result comes back

Not through a signal into the render thread: the consumer POLLS. A site that requested a build keeps drawing with what it has and asks takeReady() once per frame for the token it is waiting on (§EV-A6.3's mailbox). Results for a token nobody asks for again are dropped when the site's next result lands, so a swap for a state two edits ago never happens.