Intermittent 1px column at outer canvas edges on scene tiles

[dfattal]

Symptom

On scene (three.js) tiles, a one-pixel column is visible at each outer edge of the canvas — one eye's column at the far left of the element box, the other eye's at the far right. Instead of dissolving into the page, they read as a hard line, so the tile does not blend the way EdgeFeather intends.

Reported from a live look on Leia SR hardware (David, 2026-08-14). Affects three.js/scene tiles generally, not one sample.

Why this is the feather's problem specifically

Image and video tiles bake their own feather into the SBS buffer inside the SDK (addImage/addVideo own those buffers). Scene tiles cannot — the app owns the canvas — so the fade is a per-eye render pass, EdgeFeather in js/inline3d-three.js. If the pass misses the outermost column, that column arrives at the weave at full alpha and survives to the display as a hard edge.

Candidate causes, roughly in order

1. The ramp never reaches zero at the boundary. EdgeFeather multiplies the framebuffer by smoothstep(0.0, fx, vUv.x) * smoothstep(0.0, fx, 1.0 - vUv.x). The first texel's centre sits at vUv.x = 0.5 / vp.width, not 0 — so its alpha is small but non-zero. Small residual alpha on a bright scene against a dark page is exactly a faint hairline. Worth testing a ramp that is clamped hard to 0 over the outermost texel, or biasing the smoothstep edge so the first texel lands at or below 0.
2. Viewport rounding leaves a column neither eye writes. layer.getViewport() reports backing-store px; if the two eye viewports do not exactly tile canvas.width (odd widths, or a renderScale that rounds), a column is written by the scene pass but never covered by the feather quad — or the reverse.
3. Weave-side un-squeeze sampling. Each eye's half is stretched 2× horizontally. Clamped edge sampling can replicate the outermost source column into the destination without the fade ever applying. If so this is browser-side, not SDK-side, and the fix belongs in the weave rather than in EdgeFeather.

(1) and (2) are testable purely in-page. (3) needs the weave.

Repro

1. Open samples/hello-cube/ or samples/splat/ in the DisplayXR Browser on SR hardware.
2. Look at the extreme left and right edges of the canvas against the page background.
3. Compare against an image tile (samples/windows/), which bakes its feather in the SDK — if image tiles are clean and scene tiles are not, that isolates it to EdgeFeather and rules out (3).

That comparison is the first thing to run; it splits the candidate list in half.

Notes

• Not introduced by the viewer subpaths in feat(sdk): experimental ./viewer + ./splat subpaths — a Gaussian splat in a tile #8 — EdgeFeather predates them, and samples/splat merely uses it. Expect hello-cube to show the same thing.
• Needs a hardware eyeball to confirm any fix; the artifact is sub-pixel-adjacent and screenshots of woven output are not reliable evidence.

[dfattal]

Ran the numbers on candidate (1) and it does not survive, so demoting it.

With px = 24 and a 624-wide eye viewport, fx = 0.0385. The first texel centre sits at vUv.x = 0.5/624 = 0.0008, so t = 0.0208 and smoothstep = 3t² − 2t³ ≈ 0.0013. That is 0.13% alpha on the outermost column — far below anything visible as a hairline. The ramp is fine; it is not failing to reach zero.

Better candidate: a fractional element rect

The reporting box runs at 250% display scaling, and #tile is width:100% inside a max-width:520px centred container. Between the centring (margin:0 auto inside a 760px wrap with 20px padding) and the 2.5× device-pixel ratio, getBoundingClientRect() is very likely fractional in device pixels.

That matters because the weave takes the element rect and splits it in half. A fractional rect means:

• the half-split rounds, so the last column of the left eye and the first column of the right eye do not land on integer source columns;
• the outermost destination column maps outside the intended source and gets whatever clamped sampling gives it — which is exactly "one line of pixels for one eye at the left, another for the other eye at the right".

It also explains why this reads as a per-eye artifact rather than a symmetric border: the two eyes round in opposite directions.

Cheap discriminator

Force the tile onto integer device pixels and see if the lines disappear:

#tile { width: 512px; height: 512px; }   /* fixed, even, no % and no auto-centring */

If the artifact vanishes at an integral rect, it is rect rounding (browser-side, weave) and EdgeFeather is exonerated. If it persists, it is the eye viewports not tiling canvas.width — candidate (2) — which is fixable in the SDK.

Both take one page load to tell apart, and the answer decides which repo owns the fix.

[dfattal]

Status: not reproducing, and the fractional-rect theory is NOT confirmed

Ran the A/B on hardware in the DisplayXR Browser (Chromium 151, dpr 2.5). The artifact did not appear at all during the session, in either state of the toggle — so the experiment is inconclusive and the hypothesis in the comment above stands unproven. It is not evidence that pixel alignment fixes anything.

David also reports seeing the same thing intermittently on samples/hello-cube, which predates the viewer subpaths entirely. So:

• intermittent, not deterministic
• pre-existing, not introduced by feat(sdk): experimental ./viewer + ./splat subpaths — a Gaussian splat in a tile #8
• affects scene tiles generally

Keeping this open and tracked rather than closing it as unreproducible.

What the session did establish (measured, not inferred)

Live on hardware, samples/splat with the inline-3D session woven (mode: "3d", backing buffer 1248×624, correctly double-width):

	device px	integral?
left	467.5	✗ half-pixel
top	668.5	✗ half-pixel
width / height	1300	✓
half-width (per eye)	650	✓

So the tile's size is clean and splits exactly into two 650 px eyes — the eye viewports tile the buffer with no remainder. That rules out candidate (2) (viewport rounding leaving a column unwritten), which was the one candidate whose fix would have lived in this repo.

What remains fractional is the element's position, from margin:0 auto on a max-width container at 250% display scaling. Whether the weave's handling of that is the cause is still open — it merely survives as the last standing hypothesis, and an intermittent symptom fits a timing/state cause at least as well as a geometry one.

Better-fitting candidates now that we know it is intermittent

A pure geometry bug would be constant for a given layout. Intermittency points at rect timing instead:

1. Stale or mid-flight rect at the weave. Adjacent prior art: displayxr-browser feat(splat): setLayerRig's default viewerDistance comes from the browser's nominal viewer #83/feat(player): attachPlayer — surface mode on a splat handle (RFC 0001 A6) #85 shifted scroll rects to a measurement-time base. Anything that lets a rect arrive one frame out of step with the pixels it describes would show up first at the outermost columns, where there is no neighbouring content to mask it.
2. First frames after a re-activation. Lazy tiles create and close their weave layer on visibility; the first frame or two after re-arming is a natural window for a rect that has not settled.
3. A resize/scroll landing mid-frame, so the reported rect and the submitted buffer disagree by a fraction.

All three would present as "usually fine, occasionally a hairline", which matches the report better than a fixed half-pixel offset does.

Next time it appears — please capture this before touching anything

The artifact is the hard part to catch; the data is cheap once it is on screen. In the page console:

const c = document.querySelector('canvas'), d = devicePixelRatio, r = c.getBoundingClientRect();
copy(JSON.stringify({
  left: r.left*d, top: r.top*d, width: r.width*d, height: r.height*d,
  buffer: [c.width, c.height], dpr: d, scrollY, visible: document.visibilityState,
  sample: location.pathname,
  justScrolled: 'note whether it appeared during/after a scroll, a resize, or on first paint'
}, null, 2));

The single most useful observation: does it appear on first paint, or only after a scroll or resize? That alone separates candidate (1)/(3) from a static geometry cause, and decides whether this moves to displayxr-browser.

[dfattal]

Likely cause found, and it is the observer

A separate black-flash/flicker on the same tile turned out to happen only while the Claude-in-Chrome extension was actively driving the page (screenshots, script evaluation). With the extension idle, the same build and page were clean. David spotted the correlation.

That very likely explains this issue too: every sighting of the 1px edge column so far happened while the browser was being driven by automation. The extension sits in the compositor path the weave also uses — capture forces a readback, the debugger attach changes compositing — so it can manufacture exactly this class of artifact.

What this means for the issue

• Do not treat the fractional-rect hypothesis as the leading theory any more. It was never confirmed, and there is now a simpler explanation that also covers the intermittency (it appears when automation is active, which is intermittent by nature).
• Before investigating further, reproduce with the extension detached. Launch the page, let go of the browser entirely, and look. If it does not reproduce that way, this issue is an artefact of the test harness rather than a defect and should be closed.
• The occasional sighting on hello-cube fits the same pattern — that sample has also mostly been viewed during driven sessions.

Measurements that stand regardless

From a live woven session (Chromium 151, dpr 2.5, mode: "3d", buffer 1248×624):

• element rect: left 467.5 device px (fractional), width 1300 (integral), half-width 650 (integral)
• so the eye viewports tile the backing buffer exactly, with no remainder

That still rules out the "viewport rounding leaves a column unwritten" candidate — the one whose fix would have lived in this repo.

Separately, a per-eye render probe (renderer.info.render.calls === 0 ⇒ that eye drew nothing) recorded 0 blank eyes across 35,686 eye renders. The render path is not dropping frames.

Keeping open, but reframed

Leaving this open only to answer one question: does it reproduce with nothing driving the browser? If not, close as harness artefact.