Android inline-3D: rig zone and woven rect differ by a constant 168 px (56 dp) — double image

[dfattal]

Summary

On Android the inline-3D rig zone and the woven canvas rect disagree by a constant 168 device px vertically. The runtime therefore solves each eye's view for a zone ~1/2 inch higher on the panel than the pixels actually being woven, and the result on a 3D display is a double image — a disparity error, not a phase error.

168 px on the test device (480 dpi, density 3.0) is exactly 56 dp, the toolbar height. The zone appears to be reported in content-viewport coordinates while the weave rect is in window/surface coordinates that include the browser chrome.

Windows is unaffected and weaves correctly on the same pages.

Evidence

Two pages with different layouts and different scroll positions, same delta:

page	zone(device px)	woven rect	Δy
samples/windows (multi-canvas)	60,1558 960x960	60,1726 960x467	168
samples/hello-cube (single canvas)	60,1590 960x480	60,1758 960x435	168

Log lines:

[DisplayXR] android rig locate live: 2 views | zone(device px)=60,1590 960x480
            | bound window(device px)=0,0 1080x2193 display=0 | virtualDisplayHeight=0.12m
            | fov L/R/U/D=-0.00599997/0.135171/0.155729/-0.155729
[DisplayXR] weave zero-copy failed: BeginScopedReadAccess(canvas) (rect=60,1758 960x435)
[DisplayXR] weave window bound: origin 0,0 client 1080x2193 display 0

Note the height also differs (480 vs 435), but that part is explained: 1758 + 435 = 2193 is exactly the bound window height, i.e. the rect is clipped at the viewport bottom while the zone is not. The origin delta is the defect.

The window is bound at origin 0,0 client 1080x2193 on a 1080x2400 panel. 2400 - 2193 = 207, which is not the 168 offset — so this is not simply the bound window being wrong; the two coordinate spaces are separately derived and one of them omits the toolbar.

Why this reads as "texture size wrong" rather than "phase"

Phase errors shift the interlace comb and show as a stripe/ghost that moves with head position. This instead shows a stable doubled image at every head position, because the per-eye frusta are computed for a zone whose screen rect doesn't match the pixels being woven.

Where to look

• xrWeaveBindWindow2DXR — window geometry comes from the browser's Java UI per docs/android-port.md; likely the content view rect rather than the surface rect (or vice-versa for the zone).
• The rig zone path that emits android rig locate live: — whichever of the two is not toolbar-adjusted.
• Whatever the mac backend does here is the reference: the mac arm has no in-window chrome offset problem, and Windows passes an HWND whose client rect is consistently the origin for both.

Repro

1. Runtime + vendor plug-in installed; a 3D panel at density 3.0.
2. Launch with --enable-inline-3d --enable-blink-features=DisplayXRInline3D (via /data/local/tmp/chrome-command-line + am set-debug-app --persistent).
3. Load displayxr-web/samples/hello-cube.
4. adb logcat | grep -oE "zone\(device px\)=[^|]*|rect=[0-9]+,[0-9]+ [0-9]+x[0-9]+" and compare the two origins.

Eyeball: content weaves (all rects, both pages) but shows a persistent double image.

Notes

• The Android arm is not yet in patches/ (lives on the EC2 builder, blocked on patches 0072-0074 (web#12 canvas-readback) need a recapture refresh post-#109 #122 / epic Android port: inline-3D weave on the DisplayXR Android runtime #100), so this is filed against that work rather than a patch number.
• Separate, still open in the same session: weave zero-copy failed: BeginScopedReadAccess(canvas) / ProduceSkia(canvas) firing every frame, and inline-3D withheld N of M weave rects: no canvas resource resolved on multi-canvas pages. Those did not prevent weaving here but are worth their own look.

[dfattal]

Correction: this is a texture-SIZE mismatch, and the 168 px offset is its cause

Filing note above framed this as a translation. That was too narrow — the delivered weave texture is genuinely the wrong size, and the offset is the mechanism that makes it so. The arithmetic closes exactly on both test pages.

The transform from rig zone to submitted rect is: shift +168 px in y, then clip to the bound window. Because the shift pushes the rect past the window bottom, the clip removes real rows:

page	zone	after +168	window bottom	clipped height	submitted rect
hello-cube	y=1590 h=480 (bottom 2070)	y=1758 (bottom 2238)	2193	2193-1758 = 435	60,1758 960x435 ✓
samples/windows	y=1558 h=960 (bottom 2518)	y=1726 (bottom 2686)	2193	2193-1726 = 467	60,1726 960x467 ✓

Both predicted heights match the observed rects exactly, from two pages with different canvas aspect ratios and different scroll positions. That is conclusive for the mechanism.

Consequence: the runtime solves the per-eye rig for a zone of 960x480 (or 960x960) while the weaver receives a texture of 960x435 (or 960x467) — short by 45 and 493 rows respectively. The eye views and the woven texture therefore disagree on extent, which is a size mismatch rather than a shift.

This matters for triage because the on-screen signature is the one an experienced eye reads as wrong weave texture size, not wrong phase — a stable double image that does not move with head position. Confirmed independently by eyeball on device against a known-good Windows session on the same pages.

So there are two things to fix, and the first likely resolves the second:

1. The coordinate-space mismatch (root cause) — the zone is emitted in content-viewport space, the rect in window/surface space including the 56 dp toolbar.
2. The silent clip — even once (1) is fixed, clipping a weave rect to the window while the rig keeps the unclipped zone will reproduce this whenever a canvas is genuinely partially scrolled off-screen. The zone and the submitted texture must be clipped together, or the rig must be told the clipped extent.

(2) is worth handling on its own merits: a partially-scrolled 3D canvas is an ordinary thing for a user to do, and today it silently mis-weaves rather than degrading to 2D.

[dfattal]

Phone vs tablet: the canvas read path fails only on the phone

Ran the identical page (displayxr-web/samples/hello-cube, served over adb reverse) on both devices with the same browser build (151.0.7922.77) and near-identical runtimes (v1.21.1-924-g148a18790 tablet vs -929-g544713790 phone, five commits apart). So this is neither a browser-version nor a runtime-version difference.

Tablet (NP02J, 1600x2560 natural @ 320 dpi, used landscape) — clean:

[DisplayXR] inline-3D occlusion composite: over-plane 2560x1540 drawn=1 skipped=0

No zero-copy failures. No withheld rects. No recovery draws. Weaves correctly (human-verified).

Phone (1080x2400 natural @ 480 dpi, used portrait) — every frame:

[DisplayXR] weave zero-copy failed: BeginScopedReadAccess(canvas)
[DisplayXR] inline-3D recovery draw: n=0 missing=1 (whole-frame) [read_access=1]
[DisplayXR] weave: GPU-resident scratch path (no CPU readback)

Weaves, but shows a persistent double image.

BeginScopedReadAccess(canvas) failing means the GPU process cannot take read access on the canvas SharedImage, so the zero-copy path never runs and recovery draw: n=0 indicates the recovery pass drew nothing back. Per docs/rebase-runbook.md §6 the fallback is supposed to be visually identical — worth confirming that still holds on the Android arm, because on this device it does not look identical.

Which of the two devices is the special case is worth establishing before fixing: the phone is portrait-used with a 3.0 density, the tablet landscape-used at 2.0. Both differ from the device the Android arm was verified on (the tablet).

Also: two candidate causes ruled out this session

• Panel orientation. The plug-in reports the panel long-edge-first. Forcing it to report the natural (portrait) orientation on the phone changed the frustum materially and did not fix the double image. The model viewer, on the same stack, tracks correctly in both orientations. Not the cause.
• Per-view scale. A stale .so was briefly serving scale=0.80x1.00; corrected to 0.75x0.75 (matching the tablet) and verified in the live log. Did not fix the double image either.

Still untested (not disproven): the plug-in derives the panel's physical size from Android DisplayMetrics.xdpi/ydpi, which is ~2% larger than the CNSDK calibration's pixelSize_mm implies on this phone. The working tablet configuration is effectively calibration-derived. Tracked separately on the plug-in side.

[dfattal]

Resolved — root cause was in the Leia plug-in DP, not the browser

Fix: DisplayXR/displayxr-leia-plugin#196 (human-verified on the LPD-20W: windowed portrait ✅, fullscreen portrait ✅, landscape ✅).

The 168 px zone/rect delta this issue opened with was real but turned out to be a bystander. The actual defect: the Android DP hands CNSDK the window's top-anchored screen y, while CNSDK converts the viewport screen position into GL bottom-origin panel coordinates (interlacer.cpp: origin_gl_y = panel_h − vp_h − y). For a natural-orientation (portrait) window that doesn't span the panel, that shifts the interlace pattern by a constant (panel_h − window_h) rows — 99 on the phone (uniform double image), ~60 on the tablet (inverted views), zero at fullscreen (which is what hid it, and why landscape — which goes through CNSDK's rotation compensation — was always fine).

Diagnosis credit where due: the reporter's read that it "looked like wrong weave texture size, not phase" was the key constraint — the offset is head-position-independent, unlike tracked-phase errors, which is why it didn't present as classic phase swim.

Still open, browser-side (this issue can track them or spin off):

• weave zero-copy failed: BeginScopedReadAccess(canvas) / ProduceSkia(canvas) on the phone every frame (the tablet is clean), forcing the fallback path.
• inline-3D withheld N of M weave rects: no canvas resource resolved on multi-canvas pages.
• One design note learned the hard way: the draw-back samples the woven buffer normalized by its size, so the weaver's output must exactly match the submitted input dims — padding/oversizing on the runtime side is not an option.