Repository navigation
Dark halo around a transparent app's silhouette while a window-space layer is up — atlas is clean, artefact is post-compose #1791
Description
Symptom
On the Windows Leia panel, a transparent-overlay Unity app (lenovo-avatar, D3D12, plugin main + displayxr-unity#348) shows a dark halo around the avatar's silhouette whenever a window-space HUD layer (XrCompositionLayerWindowSpaceDXR) is up. David sees it by eye. With the HUD off there's no halo. The same happens with the plugin build before #348, so it isn't caused by the ADR-044 colour change.
Evidence: the atlas is clean in both cases
Runtime atlas captures (%TEMP%\displayxr_atlas_trigger, DXR_ATLAS_CAPTURE_RAW_ALPHA=1), same build, runtime v2.22.0, 808x640 atlas (2 views of 404x640):
| layers per frame | alpha = 255 | 0 < alpha < 255 | alpha = 0 with rgb ≠ 0 | |
|---|---|---|---|---|
| HUD off | 2 (zone projection + Local2D) | 79,536 | 3,097 (avatar AA edges) | 0 |
| HUD on (2 wsui layers) | 4 | 87,898 | 51,940 (the semi-transparent HUD panel) | 0 |
Outside the HUD panel's rect, the area around the silhouette is alpha 0, rgb 0 in both captures, with no fringe. So the layers the app submits, and the runtime's layer composition into the atlas, are correct. The halo is introduced after the atlas, in the DP/weave compose-under-desktop or the present path. That stage can't be captured today (#492).
Context
- The app's window region is
SetWindowRgn= a dilated, unclipped silhouette (displayxr-unity click-through mask, v4 rule from depth-budget: v3 rendered-silhouette mask feeds the clip state back into the measurement — rear clip oscillates on a text/margin border #1470). So a band around the avatar exists in the window with alpha 0 in the atlas, and it should show the desktop. With a window-space layer up, that band shows darker. - Possibly related to DP compose-under-bg likely applied per-layer instead of post-composite — desktop bleeds through semi-transparent window-space HUD over opaque content #225 (closed 2026-05-15): "DP compose-under-bg likely applied per-layer instead of post-composite". Same trigger (a window-space layer present), different symptom.
- Repro: lenovo-avatar Windows player (or displayxr-unity-samples
desktop-avatar, which has the same HUD + bubble setup), transparent session, toggle the HUD with Shift+Tab, look at the silhouette edge against a light desktop.
Ask
Whoever owns the DP compose-under-desktop / weave present path: can you check whether the alpha-0 region gets different treatment when the frame carries a window-space layer, e.g. the multi-layer compose path vs the fast path feeding the DP? A post-weave capture (#492) would make this directly measurable.
Reported from the displayxr-unity side; atlas PNGs are available on request.
Activity
dfattal commentedon Oct 2, 2026
Not a runtime bug, closing. My diagnosis was wrong. The "halo" was the HUD's semi-transparent backdrop clipped by the app's own window region. On Windows the transparent overlay's
SetWindowRgnregion was the avatar's (dilated) silhouette, and a window region is a visual clip, so the HUD layer was only visible inside that silhouette-shaped area. It read as a dark band around the avatar. That's also why the atlas was clean: the clip happens at the window, after composition. It's fixed plugin-side by DisplayXR/displayxr-unity#351, which adds live window-space layer rects to the region, the same trick the model viewer uses for its toasts. Confirmed on the panel: no clip, no halo. Sorry for the noise.