Android: weave window origin is hardcoded (0,0), so the interlace phase is off by the status-bar inset in landscape

[dfattal]

Symptom

On the tablet (NP02J, 2560×1600 landscape) inline-3D weaves but the 3D is soft / phase-shifted — reported as "some phase offset, 3D not super clear". Fullscreen looks right; windowed (status bar visible) does not.

Root cause

patches/0089-feat-android-GPU-side-AHardwareBuffer-extraction-the.patch:337

SetWindowGeometryAndroid(/*origin_x=*/0, /*origin_y=*/0,

The origin is a hardcoded literal, while client_width/height come from the real surface. So we report an inconsistent rect: the window's origin with the surface's size.

Measured on device, windowed:

window screen rect 0,0 2560x1540 display 0        <- what we report
weave full-target screen-pos 0,0 target 2560x1540 <- phase anchored at y=0
InsetsSource ITYPE_STATUS_BAR frame=[0,0][2560,60] <- surface actually starts at y=60
Frames: frame=[0,0][2560,1600]                     <- window is edge-to-edge

The woven surface occupies rows 60..1600, but the interlace phase is referenced to row 0. The lenticular phase is absolute-screen, so a 60-row error puts every column on the wrong lens phase → crosstalk / mushy depth. Going fullscreen changes the report to 0,0 2560x1600, where origin 0 is the truth, and the error vanishes:

window screen rect 0,0 2560x1600 display 0        <- fullscreen, correct by luck

Why the phone never showed it

LPD-20W is portrait-natural. Its browser surface is 1080x2301 on a 2400-tall panel (99-row inset), and the Leia plug-in's portrait branch (leia-plugin #196 / browser #165) converts to CNSDK's bottom-origin as panel_h - surface_h - win_y = 2400 - 2301 - 0 = 99 — numerically the correct anchor, by accident, because win_y was wrongly 0 and the flip re-derived the inset. In landscape (w > h) that branch is skipped, so the hardcoded 0 is exposed raw. Two bugs cancelling in one orientation is why this shipped looking fine.

Fix

Report the true on-screen origin of the woven surface instead of the literal: the window frame origin plus the top inset actually applied to the content (view.getLocationOnScreen() on the surface view, or window origin + WindowInsets top). With a correct win_y the plug-in's existing math is consistent in both orientations — portrait then computes 2400 - 2301 - 99 = 0, which is the right bottom-origin value.

Worth doing together with a check of the plug-in side: with a truthful origin, confirm the landscape path still needs no flip (leia-plugin leia_cnsdk.cpp, the if (h > w) guard) rather than assuming it — the "landscape verified on device" note behind that guard was only ever exercised at fullscreen, where the offset is 0.

Workaround until fixed

Fullscreen the page (the hello-cube sample toggles fullscreen on tap) — the origin is then genuinely (0,0).

Environment: tablet NP02J Android 13, runtime v2.14.9, plug-in v2.6.4, browser preview-0.1.17 (the last Android APK published — later previews are Windows-only, tracked separately).

[dfattal]

Correction to the root-cause analysis above — and why this is a matched-pair change

Tracing the value end-to-end settles what the fix has to be, and shows the
"Root cause" section above contradicts itself (it calls 99 "the correct anchor"
in one paragraph and 0 "the right bottom-origin value" in another). Here is the
derivation, which supersedes both.

The chain

SetWindowGeometryAndroid(origin_x, origin_y, w, h)
→ XrWeaveWindowGeometryDXR::windowOriginOnScreen
→ oxr_weave.c:230 forwards it verbatim to the DP's per-window phase slot
→ the plug-in's win_y (leia_cnsdk.cpp:1925).

No runtime transform. The browser's hardcoded literal is the plug-in's win_y.

The math

CNSDK internally derives (per the note at leia_cnsdk.cpp:1944, citing interlacer.cpp):

origin_gl_y = panel_h - vp_h - sp_y

The physically correct anchor is the bottom-origin distance from the panel's
bottom edge to the window's bottom edge:

origin_gl_y_true = panel_h - h - win_y_true      (win_y_true = true top-origin y)

Equating the two gives the whole answer:

sp_y = win_y_true

With a truthful origin, no correction is needed at all. The #165 portrait
flip and the #173 landscape generalisation are both compensations for the
browser reporting win_y = 0. They work because substituting win_y = 0 into
sp_y = panel_h - h - win_y re-derives the top inset, which is numerically what
sp_y = win_y_true would have produced. Two bugs cancelling — in both
orientations, not just portrait.

Check against the two shipped devices, with today's code (win_y = 0):

	panel_h	h	sp_y sent	CNSDK origin_gl_y	correct?
Tablet landscape, windowed	1600	1540	60	0	✅ (window bottom == panel bottom)
Phone portrait, windowed	2400	2301	99	0	✅

And with a truthful win_y but the flip still in place:

	win_y	sp_y sent	origin_gl_y	correct?
Tablet landscape	60	0	60	❌ off by the inset
Phone portrait	99	0	99	❌ off by the inset

Consequence: this cannot ship as a browser-only fix

Fixing #173 alone regresses both devices — it re-introduces exactly the error
it removes, with the sign flipped. The change is a matched pair:

1. browser — report the woven surface's true on-screen origin.
2. leia-plugin — drop the inverse pre-apply; sp_y = win_y unconditionally.

Neither half is correct without the other, and both mixed combinations are
broken, so the pair must land behind a kill-switch and be eyeballed on device
before either is released. Proposed gate on the plug-in side: keep the flip
behind debug.dxr.leia.origin_compat (default on until a browser reporting
truthful origins is the shipping one), so an old APK keeps working and the A/B
can be done live on one device.

Blast radius is small

The flip only fires when h < panel_h_now, i.e. a window shorter than the panel.
Every other Android client (the five demo APKs) runs fullscreen, where the branch
is not taken at all — so the browser is the only app that exercises this today.

Status

Not landing this yet: it needs a device to eyeball, and it is coupled to the
plug-in. Also gated on the Android APK returning to the browser release train
(only preview-0.1.17 ever shipped one), since otherwise there is no way to
deliver the browser half.

[dfattal]

Scope correction: this is the M3 seam, not a one-line fix

The hardcoded literal is not an oversight — patch 0089 documents it as a
deliberate milestone seam, and says what closing it costs:

// M3 SEAM: the origin is a placeholder — (0,0) on display 0, i.e. "the client
// area is the whole panel". That is exactly right for the fullscreen Android
// browser window and wrong for nothing that ships today, but it is NOT the
// real answer: there is no window handle and a pure MOVE raises no resize, so
// the truth only exists in the Java UI. M3 samples
// View.getLocationOnScreen() in a Choreographer callback, ships it over
// displayxr_weave.mojom, and calls SetWindowGeometryAndroid() with it —
// replacing this line and nothing else.
SetWindowGeometryAndroid(/*origin_x=*/0, /*origin_y=*/0,

So the origin is not available in the GPU process at all.
BeginBatchSync() receives only a gfx::Size, and the value has to originate
in the Java UI. Closing it is a four-part change, not an edit to one line:

1. Java: sample View.getLocationOnScreen() on the compositor surface view in a
   Choreographer callback (a pure window MOVE raises no resize, so polling on the
   frame callback is the only signal).
2. displayxr_weave.mojom: a browser → GPU message carrying the origin.
3. GPU: cache it and feed SetWindowGeometryAndroid from the cache.
4. leia-plugin: drop the inverse pre-apply (see the derivation in the previous
   comment) — the two halves must land together.

The seam comment's "replacing this line and nothing else" describes the last
step of M3, once 1-3 exist. They do not.

Consequences for sequencing

• This is M3-sized, and it needs a device to eyeball, since the correctness
  criterion is "does the 3D look crisp windowed and fullscreen, in both
  orientations".
• It is blocked on the Android build lane, which was never written — see
  the note below. There is currently no path to ship an Android browser build at
  all, so there is no way to deliver step 3 even if it were written today.
• ADR-033 still holds and constrains the design: the browser reports geometry and
  nothing else; the weaver alone owns phase and snapping. Step 1-3 must not
  "helpfully" pre-correct anything.

Workaround is unchanged

Fullscreen the page — the origin is then genuinely (0,0) and both bugs vanish
together.