Repository navigation
fix(weave/android): the overlay is per submit, and an unreadable one refuses (XR_DXR_weave v18) - #1835
Merged
Conversation
…refuses (XR_DXR_weave v18) Two gaps in the Android weave engine's v4 overlay handling, found while porting the browser's whole-page overlay (browser-pvt#226) to Android: 1. A cached overlay was a STANDING overlay. The engine caches the overlay import by AHardwareBuffer identity (the caller re-sends the same buffer every frame), and composited mc->weave.overlay_image whenever it was set - so after one submit that chained an overlay, every later submit was composited with it, chained or not. The browser's whole-page overlay switches itself off while the page scrolls (its 0351 safety floor); on those frames the last page it sent would be composited over a page that has moved. The import is still cached (no re-import for the same buffer), but the overlay is now composited only on a submit that chains one (mc->weave.overlay_this_submit). 2. An overlay that could not be imported was DROPPED and the frame woven anyway, returning success. A caller that hands its whole 2D over as the overlay reads "accepted with the overlay chained" as "composited" and presents the woven output as the complete frame. The submit is now refused (XRT_ERROR_WEAVE_REFUSED -> XR_ERROR_RUNTIME_FAILURE) before anything is recorded, so the woven output is left exactly as the previous accepted submit left it: the desktop-Linux v16 rule (#1825) and the D3D11 service's. One WARN on the first refusal, then 1 in 300. XR_DXR_weave SPEC_VERSION 18: no new structure, the Android gate for the one kind of caller that needs it (overlay == its 2D), exactly as v16 is on desktop Linux. The macOS engine still drops an unreadable overlay. Callers whose overlay decorates content they present anyway (0099's over-plane mode) see no difference except on a frame that chains no overlay, which no longer shows the previous frame's. Not tested on hardware: the NP02J is off the bus right now. Compiled by CI (build-android). The branch feat/android-overlay-2d-dp (DP-side overlay offer) touches the same block; its offer must also require overlay_this_submit once both land. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Renumbered v17 -> v18 on rebase: main took v17 for the desktop-Linux stale-size overlay rule (#1837).
dfattal
force-pushed
the
fix/android-weave-overlay-per-submit
branch
from
October 7, 2026 07:33
875b383 to
97f9ac9
Compare
dfattal
changed the title
Collaborator
Author
|
Rebased onto main. #1837 took XR_DXR_weave v17 for the desktop-Linux stale-size overlay rule, so this is now v18: header, spec doc (§5d + version table) and code comments. No functional change. |
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two gaps in the Android weave engine's v4 overlay handling, found while porting the browser's whole-page overlay to Android (DisplayXR/displayxr-browser-pvt#226):
AHardwareBufferidentity, andoverlay_imagewas composited on every later submit, whether or not it chained an overlay. The whole-page overlay switches itself off while the page scrolls, so on those frames the last page it sent would land over a page that has moved. Now the overlay is composited only on a submit that chains one (overlay_this_submit); the import cache is kept.XR_DXR_weaveSPEC_VERSION 17, no new structure: the Android gate for callers whose overlay is their whole 2D, the same role v16 plays on desktop Linux. Header text and spec doc (§5d + the version table) updated. macOS still drops an unreadable overlay.Compatibility
For callers whose overlay is decoration over content they present anyway (browser 0099 over-plane mode), the only change is on a frame that chains no overlay: it no longer shows the previous frame's overlay.
Overlap
feat/android-overlay-2d-dp(the DP-side overlay offer, 2D under the lens) touches the same block. Once both land, itsset_overlay_2doffer must also requireoverlay_this_submit.Test plan
build-androidcompiles it--inline-3d-dp-overlay-page(browser-pvt PR to follow) on a page with text around a tile. Scroll, then stop: no stale page during the scroll.--inline-3d-dp-overlay) unchangedNot tested: nothing has run on hardware yet; the NP02J is currently disconnected.
🤖 Generated with Claude Code