@vitreajs/vitrea 0.13.0 → 0.15.0

package/dist/index.d.ts

@@ -1812,6 +1812,50 @@ interface MaterialOptics {
      * not carry this constant renders the W23 material byte for byte.
      */
     readonly rimLitExponent: number;
+    /**
+     * **The lit edge's along-side field (W25; claims §5.113, W25 Decision Log 3
+     * (c))** — the slope of the position field the rim's amplitude is graded by
+     * across the surface, riding `sizeThickness`.
+     *
+     * W24 gave the rim a factor of the NORMAL, which is one number on a whole
+     * straight side. W25 G0 read the rim's peak excess by POSITION along each
+     * straight side instead and found it graded on every thick cell of both probe
+     * grids, on flat solid backdrops where a lens has no gradient to refract: the
+     * 1x dark `dark-solid__rrect-md` reads slopes of −0.000192 (top), +0.000192
+     * (bottom), −0.000379 (left) and +0.000379 (right) luma per CSS px, and the
+     * corner-to-corner range 0.0187 / 0.0226 / 0.0345 on `light-solid` /
+     * `dark-solid` / `mid-dark-solid` at span 96 falls to 0.0000 / 0.0016 at spans
+     * 32 and 44 and saturates above 96 — the signature of a term on
+     * `sizeThickness` and not of the lens.
+     *
+     * **The field is the product of the two normalised coordinates, and that is
+     * what the four slopes say.** A field linear in position — `a·x + b·y` — gives
+     * the top and the bottom side the SAME slope in x; the reference's are equal
+     * and opposite. `(x / halfWidth) · (y / halfHeight)` gives exactly the measured
+     * antisymmetry, is +1 at the top-left and bottom-right corners and −1 at the
+     * other two — the same diagonal `rimLitAxis` is symmetric about, which is why
+     * this is the position half of one light and not a second one — and predicts
+     * the two sides' slope ratio as the box's aspect: 160/96 = 1.67 against the
+     * measured 0.000379 / 0.000192 = 1.97, where a metric diagonal would predict
+     * 1.0. Reading the reference's two sides through it gives 0.62 (top) and 0.73
+     * (left) for this constant, which is the agreement a 56 CSS px straight side
+     * on a six-code contrast supports.
+     *
+     * The factor is `1 + rimAlongSideSlope · sizeThickness(span) · field`, applied
+     * beside W24's `lit` factor and outside W23's amplitude bracket. Two
+     * consequences are exact rather than approximate. **The field's mean over every
+     * straight side is zero**, because the product is odd in the coordinate that
+     * runs along the side, so W23's and W24's straight-span amplitudes keep their
+     * fitted meaning and the CSS tier — whose one inset shadow cannot vary around a
+     * contour — is coherent with the GPU tier's side mean without carrying the term
+     * at all. **It is exactly 0 at or below `sizeSpanMin`**, so `rrect-sm` and every
+     * thin control are untouched by construction; the capsule's span of 44 takes
+     * 0.0923 of it, which is the thin end's whole exposure.
+     *
+     * At 0 the factor is exactly 1 everywhere, so a profile that does not carry
+     * this constant renders the W24 material byte for byte.
+     */
+    readonly rimAlongSideSlope: number;
     /** Inner-shadow depth (0..1) and how much of it is applied. */
     readonly shadowDepth: number;
     readonly shadowAlpha: number;
@@ -2171,6 +2215,17 @@ interface MaterialProfile {
      * σ 10 device px against a body σ of 1.25, and the gain sweep has a clear
      * minimum at 8 (RMS 0.0164 against 0.0180 at 6 and 0.0191 at 10 on the probe
      * bed).
+     *
+     * **INERT on the GPU tier at any material that names a heavy width** (W26;
+     * claims §5.122 §6a). This constant reaches the deep sample only through
+     * `scatterLod`, and where `sizeHeavyTapSigma` is non-zero the optics pass
+     * overwrites that sample with the heavy texture — measured, not argued: fifty
+     * rows byte-identical between `sizeScatterGainFar2x` 9.9 and 4.8 at the landed
+     * width. It is KEPT and not retired because retiring it means deciding what a
+     * profile naming NO heavy width draws, which is a code-removal wave with no
+     * fidelity content (W26 Decision Log 6 (b)); the tracker carries it. The CSS
+     * tier still reads it for the same reason — the collapsed single-`blur()` form
+     * and the sampling-padding projection, where no heavy width applies.
      */
     readonly sizeScatterGainMax: number;
     /**
@@ -2290,6 +2345,11 @@ interface MaterialProfile {
      * **The span top, 256** — the 1x value, unchanged, because a floor of 1
      * leaves the deep value nothing to rise to and the top has no work at this
      * ratio. Stage 1 swept it against 128 and the bed did not ask for the change.
+     *
+     * **The gain is INERT on the GPU tier at any material that names a heavy
+     * width** (W26; claims §5.122 §6a), for `sizeScatterGainMax`'s reason and with
+     * the same measurement behind it. The floor and the span top above are NOT —
+     * they grade the deep value's SHARE, which the heavy texture does not touch.
      */
     readonly sizeScatterGainMax2x: number;
     readonly sizeScatterFloor2x: number;
@@ -2339,6 +2399,19 @@ interface MaterialProfile {
      * 0.1125 → 0.0993 against native 0.1018 at 9.9, which is the sweep's best on
      * its own objective. The confirmation's holdout `rrect-lg` rose 0.9661 →
      * 0.9762 with its interior spread 0.0721 against native 0.0810.
+     *
+     * **INERT on the GPU tier at any material that names a heavy width**, and this
+     * is the one of the three whose silence costs something (W26; claims §5.122
+     * §§3, 6a). It is the constant that graded the 2x heavy width with the span,
+     * and the heavy texture is one width per SOURCE, so where a heavy width is
+     * named there is nothing left for it to grade: fifty rows byte-identical
+     * between 9.9 and 4.8 at the landed width. What that gives up is measured on
+     * the instrument of record rather than estimated — the reference wants **1.66
+     * device px more heavy width at span 160 than at span 96 at dpr 2**, 20 % of
+     * the smaller, and W26 lands one number inside 11 % of each instead. That is
+     * W26 Decision Log 2 (f)'s recorded gap, now with a size; the constant is kept
+     * against the profile that names no heavy width and against the wave that
+     * makes the width per surface.
      */
     readonly sizeScatterGainFar2x: number;
     /**
@@ -2489,6 +2562,210 @@ interface MaterialProfile {
     readonly sizeScatterRampStartFar2x: number;
     readonly sizeScatterRampReach1xPx: number;
     readonly sizeScatterRampReach2xPx: number;
+    /**
+     * **The heavy share's thick end** (W25; claims §5.113, W25 Decision Log 3 (a))
+     * — how much heavier the deep value runs on a thick surface than the span
+     * curve above makes it, riding `sizeThickness` and read once per scale.
+     *
+     * W25 G0 measured the reference's kernel as TWO components and found that what
+     * separates the thick surface from the thin one is neither width: read on the
+     * same cell at 1x the reference's single-Gaussian width is 1.30 device px
+     * against a 16 CSS px checkerboard, 4.75 against 32 and 6.25 against 64, where
+     * one Gaussian returns one number at every pitch. The dot's own two-component
+     * fit on `impulse__rrect-md` reads sharp σ 2.79 and heavy σ 19.52 device px at
+     * 1x and 1.40 / 11.29 at 2x — both components HALVING in device px — with the
+     * heavy SHARE moving 0.47 → 0.69 the other way, and 0.00 on the collapsed
+     * capsule. vitrea's own pair on the landed material reaches 0.69 at 2x and
+     * carries 0.23 at 1x. So the share is the quantity, and this is where the wave
+     * puts it.
+     *
+     * ```
+     * kDeep(span, dpr) = floor(dpr) + (1 − floor(dpr))
+     *                    · smoothstep(sizeSpanMin, sizeScatterSpanMax(dpr), span)
+     *                  + heavyShareThick(dpr) · sizeThickness(span)      ← this
+     * ```
+     *
+     * **What stays, and why the thin capsule cannot move.** `sizeScatterFloor`,
+     * `sizeScatterSpanMax` and the ramp's start anchors are NOT re-derived: the
+     * W11c curve stays as the law's thin end and this constant is the lift the
+     * thick end takes above it. That is X5 discharged by the form rather than by a
+     * capture — `sizeThickness` is exactly 0 at and below `sizeSpanMin`, so
+     * `rrect-sm` and every smaller control are bit-identical whatever this says,
+     * and the capsule at span 44 takes 0.0923 of it, which is the whole of the
+     * thin end's exposure and is what the ladder's thin-invariance rung reads. The
+     * alternative — re-expressing the whole curve on a thin/thick anchor pair —
+     * would have made the capsule's own share a fitted quantity of this wave, and
+     * the reference does not ask for that: its sharp σ is 2.62 device px on the
+     * collapsed capsule against 2.79 on the thick rrect, span-flat to 6 %.
+     *
+     * **Inert at 0**, which is what ships until G3 declares the fit: the term is
+     * one multiplication by zero added to the curve W11c fitted, so the resolved
+     * material and every golden are byte-identical to the W24 bed.
+     *
+     * At dpr 2 the 2x anchor is additionally inert on the landed material for a
+     * second reason: `sizeScatterFloor2x` is 1, so `kDeep` is already 1 at every
+     * span and the clamp absorbs any lift. The 2x share is therefore not a
+     * quantity this bed can carry, and it waits for G1's 2x probe fixtures.
+     */
+    readonly sizeScatterHeavyShareThick1x: number;
+    readonly sizeScatterHeavyShareThick2x: number;
+    /**
+     * **The body's level above the thickness knee** (W25; claims §5.113, W25
+     * Decision Log 3 (b)) — an OFFSET on the interior level a surface settles at,
+     * in the tone response's own encoded units, reached at `sizeScatterSpanMax`.
+     *
+     * W25 G0 answered clause 4 in the landed law's favour and found one residual
+     * it cannot carry. `sizeThickness(short side)` at knee 96 scores r 0.95–0.998
+     * against 0.68–0.96 for the long side, the area, √area and the radius, on the
+     * width and on the level, in both probe grids and both schemes — so the
+     * argument and the knee stay. But the reference's body LEVEL keeps grading
+     * above 96: on the W9 light grid over `checkerboard` it reads 0.61484 /
+     * 0.61299 / 0.67915 / 0.69083 / 0.70458 across spans 32 / 44 / 96 / 128 / 160,
+     * where `sizeThickness` has been flat since 96. The width does not grade there
+     * on any pitch; only the level does.
+     *
+     * ```
+     * R(x, span, dpr) = R₀(x, sizeK)
+     *                 + sizeToneLevelFar · smoothstep(sizeSpanMax,
+     *                                                sizeScatterSpanMax(dpr), span)
+     * ```
+     *
+     * **Where it enters.** On the tone response's OUTPUT — the settled interior
+     * level `backdropToneResponse` returns, which is the law that owns the
+     * interior mean (claims §5.33) — and not in the blur, not on a gain on the
+     * mix, and not (this is the correction) on the response's own thin-to-thick
+     * blend.
+     *
+     * **Why not on the blend, which is what the wave chartered.** G0's reading
+     * that the residual's "sign follows the backdrop" is a reading of the
+     * REFERENCE's absolute grading, and the quantity a term has to close is the
+     * residual AGAINST vitrea, whose own deep value keeps rising to
+     * `sizeScatterSpanMax` over the same spans. G2's ladder measured both shapes
+     * on the same rows (`fit-level.txt`): carrying the blend past the thick row
+     * explains 0.3 % of the above-knee residual and its per-row gains run
+     * −1.13 … +0.24 with the two grids disagreeing in sign, because the blend's
+     * direction is different at every backdrop level and the residual's is not. An
+     * offset explains 11 % of it and the light grid's rows agree: `resid(160) −
+     * resid(96)` is +2.2 … +4.2 codes over `checkerboard` at four pitches,
+     * `dark-solid`, `mid-dark-solid`, `hc-text` at two pitches and `photo`, over
+     * backdrops spanning 0.012 to 0.89 linear. Backdrop-independent is what the
+     * rows say, so backdrop-independent is the shape.
+     *
+     * The curve is the one the ramp's far anchor declines along and the 2x heavy
+     * gain rises along, so no new span statistic enters the material, and it is
+     * **exactly 0 at and below `sizeSpanMax`** — nothing at or under span 96 moves
+     * at any value of this constant, which is what let G2 probe it against the
+     * frozen bed with 77 control rows reading a lever of 0.000000 codes per unit.
+     *
+     * Folded with `sizeK`, like the response it offsets: under reduced
+     * transparency the material has stopped transmitting and the level it settles
+     * at is the preference's, not the size law's.
+     *
+     * **Inert at 0**, which is what ships until G3 declares the fit. What G2's
+     * ladder read is in `fit-level.txt`; the constant is weakly conditioned on the
+     * bed as it stands and G1's probe set at both scales is what would condition
+     * it (G0 §6: 118 level rows on the 1x grids, 202–238 with the 2x captures).
+     */
+    readonly sizeToneLevelFar: number;
+    /**
+     * **The heavy blur's width, in device px per scale** (W26; W26 Decision Log 1
+     * and 2, from the measured cause in claims §5.116 §2) — the constant that makes
+     * the deep sample's width a continuous parameter instead of a chain level.
+     *
+     * W25 could not raise the heavy share because vitrea's heavy component is
+     * 13.3 device px at 1x against the reference's 19.5, and raising the share at
+     * the wrong width adds narrow structure the reference does not have. The width
+     * was not a lever: `sizeScatterGainMax` 8 → 10.3 left reader A at 13.29. W26 G0
+     * measured why, and it is arithmetic rather than material
+     * (`results/2026-09-10-w26-heavy-width/g0/tap-today.txt`). The body's deep
+     * sample is
+     *
+     * ```
+     * scatterLod = clamp(bodyChainLod + log2(gain), 0, chainMaxLod)
+     * ```
+     *
+     * `chainMaxLod` is `planPyramid`'s `levelCount − 1`, and the chain stops when
+     * the shorter side would fall below `MIN_LEVEL_EXTENT` = 8. On the bed's
+     * 320 × 200 backdrop raster the chain is five levels, so `chainMaxLod` is **4**
+     * at dpr 1, and `bodyChainLod + log2(8)` is 4.06 — **already past the clamp**.
+     * Every gain at or above 7.5 draws the same level 4, whose own kernel is
+     * 13.4 level-0 texels wide (`CHAIN_LEVEL_SIGMA`) — which is the 13.3 the ledger
+     * recorded. G0 rendered the three impulse rows at gains 8, 10.3, 16 and 32 and
+     * read them identical to the last digit, moving only at gain 4, which asks for
+     * level 3.06 and gets it. So `sizeScatterGainMax`, `sizeScatterGainMax2x` and
+     * `sizeScatterGainFar2x` grade a quantity the clamp then discards, and a
+     * fractional level or a blend of two levels cannot widen anything at dpr 1 —
+     * G0 measured both **inert to the bit** there and removed them again (W26
+     * Decision Log 2 (a); the branch and `results/…/g0/` are their record).
+     *
+     * What widens is a Gaussian, and it is built where the chain is built. The
+     * pyramid takes the chain level whose own blur is nearest below this σ and runs
+     * the two separable passes it already runs for the body until the total is this
+     * σ exactly (`heavyTapPlan`, `PyramidResources.heavy`), so the width is
+     * continuous and is bounded by nothing the chain's depth decides — the residual
+     * carries whatever octave the chain lacks. The optics pass then reads that
+     * texture in place of the chain tap.
+     *
+     * **Per scale**, resolved by `rampAtScale` on the pattern `sizeScatterGainMax2x`
+     * established, because the reference's heavy component is a device-px quantity
+     * that does not simply halve between the scales (19.52 at 1x, 11.29 at 2x;
+     * claims §5.113 §2) — so a profile naming only the 1x end drags the 2x end
+     * toward the 2x constant's own default, and a document that means both names
+     * both.
+     *
+     * **At 0 the mechanism does not exist**: no texture is allocated, no pass is
+     * encoded, and the optics pass takes the single `textureSampleLevel` of the
+     * chain the material has always taken. That is what makes the landed 0.14.0
+     * goldens byte-identical.
+     *
+     * **What it costs, and what it gives up.** One texture and two passes per
+     * source per frame — 0.070 ms on the mobile bench row, against +1.1 ms for the
+     * in-shader grid G0 measured (W26 Decision Log 2 (b)). The width is then one
+     * per SOURCE rather than one per pixel, so the span grading `sizeScatterGainFar2x`
+     * carried does not reach the deep sample where this is on. The reference's heavy
+     * width does not grade with the span at 1x (claims §5.113 §4), which is what
+     * says the material can afford that; at 2x it does (the `-lg` row reads 16.92
+     * against `-md`'s 11.29), and that is a recorded gap rather than an answered
+     * one (W26 Decision Log 2 (f)).
+     *
+     * ---
+     *
+     * **WHAT WAS THEN MEASURED, and it moved the target as well as the width**
+     * (W26 G1b and G1c; claims §5.121 and §5.122; W26 Decision Log 5 and 6 (a)).
+     * The readings quoted above — 19.52 at 1x, 11.29 and 16.92 at 2x — are
+     * two-Gaussian fits to ONE backdrop each, and the same reference reads 8.4
+     * through `checkerboard-64` where it reads 19.5 through the impulse tile. They
+     * stand as recorded, with these beside them.
+     *
+     * The instrument of record is the family reader: the composite this renderer
+     * actually computes, fitted to the pixels jointly across every thick untinted
+     * backdrop of one surface, with a per-backdrop gain. It is the only reader in
+     * this wave that was held against a control — it returns vitrea's OWN drawn
+     * width to 0.6 % — and on it **Apple's heavy width is 8.6–9.2 device px at
+     * dpr 1 and 8.7–9.6 at dpr 2**, on both surfaces and in both schemes, with the
+     * share already right to 0.07. So the 13.418 the clamped tap drew at dpr 1 was
+     * half again too wide, and the reason two waves could not raise the share is
+     * that more of a too-wide heavy component is more of the wrong thing.
+     *
+     * **The landed 9 and 9**, fitted through a ladder the reader sees one for one
+     * (slope 0.995–1.111, rms 0.03–0.06 device px over seven rungs from 8 to
+     * 13.418), inverted per cell: 9.48 / 8.63 / 9.19 at dpr 1 and 8.13 / 9.79 /
+     * 8.37 at dpr 2. At dpr 1 the spread is 9.8 % and one number serves both spans;
+     * at dpr 2 it is 20.4 % and one number does not, which is the span grading of
+     * the paragraph above, now measured at 1.66 device px.
+     *
+     * **The mechanism has no small values** (W26 Decision Log 6 (c)). The paragraph
+     * above says the mechanism does not exist at 0; the counterpart is that it does
+     * exist at 0.001, where `heavyTapPlan` selects chain level 0 with a residual of
+     * a thousandth of a texel and the deep sample becomes the UNBLURRED backdrop.
+     * A near-zero σ is therefore the opposite of "almost off" — it is the widest
+     * possible departure from the material — and a profile must name 0 or a real
+     * width and nothing between. The domain is 0 or at least the chain's level-1
+     * width; a floor in `heavyTapPlan` would make it continuous, and the tracker
+     * carries it.
+     */
+    readonly sizeHeavyTapSigma: number;
+    readonly sizeHeavyTapSigma2x: number;
     /**
      * The occlusion gain — "a larger size is more opaque. A smaller size is
      * clearer" (S284). The fraction of the *remaining* transparency the size law
@@ -2952,6 +3229,11 @@ interface MaterialProfilePatch {
     readonly sizeScatterRampStartFar2x?: number;
     readonly sizeScatterRampReach1xPx?: number;
     readonly sizeScatterRampReach2xPx?: number;
+    readonly sizeScatterHeavyShareThick1x?: number;
+    readonly sizeScatterHeavyShareThick2x?: number;
+    readonly sizeToneLevelFar?: number;
+    readonly sizeHeavyTapSigma?: number;
+    readonly sizeHeavyTapSigma2x?: number;
     readonly sizeOcclusionGain?: number;
     readonly sizeShadowGainMax?: number;
     readonly lensRefractionGain?: number;
@@ -3736,6 +4018,7 @@ interface RebuildLedger {
  * import      provider frame  ->  chain mip 0     (premultiplied linear, X5)
  * downsample  mip n-1         ->  chain mip n     (13-tap, one pass per level)
  * blur x2     chain[bodyLvl]  ->  body            (separable, residual sigma)
+ * blur x2     chain[heavyLvl] ->  heavy           (separable, residual sigma; W26)
  * analysis    chain[anaLvl]   ->  stats buffer    (compute, one workgroup)
  * ```
  *
@@ -3750,6 +4033,23 @@ interface PyramidResources {
     readonly plan: PyramidPlan;
     readonly chain: GPUTexture;
     readonly body: GPUTexture;
+    /**
+     * The **heavy** blur (W26; `MaterialProfile.sizeHeavyTapSigma`) — one more
+     * texture beside the body, built by the same two separable passes from
+     * whichever chain level `heavyTapPlan` names, and `undefined` where the
+     * profile asked for no width.
+     *
+     * It is here rather than in the optics pass because the optics pass is a
+     * fragment shader over the glass's own area: W26 G0 measured a 9 × 9 in-shader
+     * grid at +1.1 ms on the mobile bench row against 0.070 ms for the two
+     * separable passes the chain already runs (W26 Decision Log 2 (b)). The price
+     * of building it here is that the width is **one per source** rather than one
+     * per pixel — every group sampling this source gets the same heavy width,
+     * because the texture is built before any group is drawn. The reference's heavy
+     * width does not grade with the span at 1x (claims §5.113 §4), which is what
+     * says the material can afford that.
+     */
+    readonly heavy: GPUTexture | undefined;
     readonly stats: GPUBuffer;
     /** Source size epoch this allocation was made for. */
     readonly sizeEpoch: number;
@@ -3787,6 +4087,14 @@ interface PyramidResources {
      * chain's body and `bodyChainLod` belong to the previous scale.
      */
     readonly bodySigmaCss: number;
+    /**
+     * The heavy blur's σ in **CSS px** the build converted with, for `sameBody`'s
+     * reason and by the same rule: the heavy width is a device-px quantity
+     * (claims §5.113 §2), so `sizeHeavyTapSigma / dpr` is what reaches the source's
+     * texels, and a window dragged between displays asks for a different heavy
+     * texture from the same clean source.
+     */
+    readonly heavySigmaCss: number;
 }
 interface PyramidInstrumentation {
     /** Successful rebuilds since the store was created. */
@@ -3816,6 +4124,12 @@ interface PyramidBuildRequest {
      * The build resolves it once the frame's real extent is known.
      */
     readonly bodySigmaCss: number;
+    /**
+     * The heavy blur's σ in **CSS px** (W26), 0 where the profile declines the
+     * width — at which point nothing is allocated and nothing is drawn, so a
+     * material that names no heavy width pays for none of this.
+     */
+    readonly heavySigmaCss: number;
     readonly viewportCss: readonly [number, number];
     /**
      * Where the source sits on the plane, in CSS px relative to the viewport, if

package/dist/index.js

@@ -1092,7 +1092,7 @@ function isHealthy(state) {
 
 // src/renderer-seam.ts
 async function loadWebGPURendererModule() {
-  return import('./dist-2V7EQHSR.js');
+  return import('./dist-PT4PUS4K.js');
 }
 async function loadWebGPURenderer() {
   const { createWebGPURenderer } = await loadWebGPURendererModule();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vitreajs/vitrea",
-  "version": "0.13.0",
+  "version": "0.15.0",
   "description": "Framework-agnostic Liquid Glass material runtime: scene model, capability resolution, material policy, accessibility policy.",
   "license": "Apache-2.0",
   "homepage": "https://github.com/SSFSKIM/designer",