Repository navigation
fix(#291): window-space UI aspect from the composited window, not Screen.* - #349
Merged
Merged
Conversation
… window, not Screen.* In a transparent-overlay app Unity's own window is cloaked and parked, so Screen.* reports whatever size Unity persisted (observed 512x728 and 3872x2248 next to a 3840x2160 overlay; it grows by the window frame on every run). DisplayXRWindowSpaceUI derived its RT aspect from it, so the runtime's stretch into the panel rect was not the identity and the HUD came out squeezed (lenovo-avatar's radio/tuning HUDs). The provider now publishes the live size of the window (or workspace tile) the runtime composites into, the number the eye swapchain is already sized from, as a cached value (dxr_prov_get_composited_size). On Linux the measurement uses the X connection the runtime borrows, so it must not be queried from Unity's main thread. The window-space UI prefers it over Screen.*, after the workspace-tile canvas (#323). It falls back to Screen.* with no provider session or against an older native plugin. Only the aspect is used, so the native-DPI pixels need no conversion. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…HUD rects are fractions of Apps that lay out HUD rects (e.g. lenovo-avatar's HudPanelLayout) used Screen.* so their math matched the RT aspect the component derived from it. With the composited-window source that is no longer the same number in a transparent-overlay app on Windows, so expose the component's own source chain (workspace tile, then composited window, then Screen.*) as a public static. The shell-mode and size helpers become static to share it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dfattal
marked this pull request as ready for review
October 2, 2026 08:58
dfattal
added a commit
that referenced
this pull request
Oct 2, 2026
…from the merged source Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
Fixes #291 for transparent-overlay apps: lenovo-avatar's radio and tuning HUDs rendered squeezed.
Root cause:
DisplayXRWindowSpaceUIderived its RT aspect fromScreen.*. In a transparent-overlay app that's Unity's own cloaked, parked window, at whatever size Unity persisted. On the Windows panel box we sawScreen= 3872x2248, then 512x728 after clearing the persistedScreenmanager Resolution(it grows by the frame size, +32x88, every run). The window the runtime actually composites into was 808x1280 (portrait), so the runtime's stretch into the panel rect was far from the identity.Change
ps_window_sizepublishes every real measurement (tile canvas, or the bound window's client) into an atomic cache. The new exportdxr_prov_get_composited_size(w, h)returns it while a session runs. It's deliberately a cached value: on Linux the measurement goes through the X connection the runtime borrows, which must not be driven from Unity's main thread (see feat(#332): Linux displayxr_is_our_process_foreground #335, and the feat(#332): Linux click-through and right-drag move for the transparent overlay #346 review). The cache resets at session stop.DisplayXRWindowSpaceUI.TryGetPanelPixelSizesource order is now workspace tile (WindowSpaceUI overlay stretches with the workspace tile under the shell: panel aspect is read from Screen.* instead of the tile size #323) → composited window →Screen.*. It falls back cleanly with no provider session or against an older native plugin (EntryPointNotFoundException→ never asked again). Only the aspect is used, so the native-DPI pixels need no conversion.Testing
Windows Leia panel, runtime v2.22.0, lenovo-avatar (transparent overlay, Gamma) built against main + #348 + this branch, D3D12:
No errors or WARN lines. On-panel eyeball by David is pending.
Not covered yet: Linux (Byungju), the editor docked path (the composited size there is the Game-view pane, the same thing the eyes are sized from), and the shell (unchanged: the tile source still wins).
🤖 Generated with Claude Code