Skip to content

fix(multi): macOS shared-surface content draws through the _SRGB atlas view (#1801) - #1802

Merged
dfattal merged 1 commit into
mainfrom
fix/macos-oop-srgb-client-content
Oct 3, 2026
Merged

dfattal merged 1 commit into
mainfrom
fix/macos-oop-srgb-client-content

Conversation

@dfattal

@dfattal dfattal commented Oct 3, 2026

Copy link
Copy Markdown
Collaborator

Fixes #1801.

Problem

On the macOS service's shared surface, every app that declares an _SRGB colour swapchain is drawn one sRGB decode too dark. render_shared_surface_locked() samples each client as its declared format (so _SRGB is hardware-decoded to linear), then draws into the encoded B8G8R8A8_UNORM atlas through its UNORM framebuffer. Nothing re-encodes.

Fix

  • The content pass now uses the target vk_native window-space + all-backend Local2D are not format-honest (ADR-044 §7) #1795 resolves for the decorations (shared_resolve_deco_target): the atlas's _SRGB view, or the atlas itself when it is _SRGB. Content and decorations are now on one rule.
  • The focus-glow style colour is display-referred, so it is decoded on the CPU before it reaches an encoding target (u_color_srgb_decode, constants only, next to the encode oracle).
  • DXR_COLOR_LEGACY_UNORM_ENCODED=1 keeps the old UNORM target, byte for byte.
  • ADR-044 §7 now records the exception.

macOS only: the function is inside #ifdef XRT_OS_MACOS. The Android and Linux service flavours are untouched and remain unaudited.

Behaviour change, per the contract: a UNORM client on this surface is now read as linear and encoded, the same as vk_native. An app that writes display-referred bytes into UNORM looks washed out here too, and the fix for that is app-side (ADR-044 §2).

Verification (pre-weave atlas, macOS arm64, sim_display, cube_handle_vk_macos in the workspace, shell-pvt main with #122)

The atlas was dumped with a local, uncommitted readback after the decoration pass.

config brightest-20k-px mean lum static floor grid
before, _SRGB client 61 too dark to register
UNORM-passthrough reference (before, client UNORM) 131 (13,13,26)
after, _SRGB client 120 (13,13,25)
after + legacy hatch, _SRGB client 65 —
after, UNORM client (DXR_SWAPCHAIN_ENCODING=unorm) 190 (encoded, per contract) (64,64,90)

The gap between 120 and 131 comes from the cube rotating between captures. The grid is static, and it matches the reference.

The shell chrome bytes (title pill, text, close button, backdrop) are identical to the #1795 captures.

Tests:

  • tests_aux_color_encoding: decode → encode round-trips all 256 bytes.
  • tests_comp_color_policy: new pin that the content pass resolves its target and never begins on the bare UNORM framebuffer. Mutation-checked: reverting the begin call fails it.

Not done

  • No eyeball on a real 3D panel (sim_display anaglyph only).
  • Unrelated and pre-existing, seen during testing: the macOS service sometimes aborts on SIGTERM, with an os_mutex_lock assert in common_shutdown on a client thread. Crash reports exist from before this change.

🤖 Generated with Claude Code

…s view (#1801)

The macOS service composites each client with comp_multi_content_blend,
sampling it as its DECLARED format, but drew into the encoded atlas through
its UNORM framebuffer. An _SRGB client (the ADR-044 recommended choice) was
hardware-decoded and stored raw, one decode too dark.

The content pass now takes the target #1795 resolved for the decorations:
the atlas's _SRGB view (or an _SRGB atlas). The focus-glow style colour is
display-referred and is decoded on the CPU before it reaches an encoding
target (new u_color_srgb_decode, for constants only).
DXR_COLOR_LEGACY_UNORM_ENCODED=1 keeps the old UNORM target.

Measured on the pre-weave atlas (macOS arm64, sim_display,
cube_handle_vk_macos in the workspace):
- _SRGB client: brightest-px luminance 61 -> 120; the static floor grid is
  (13,13,25), matching the UNORM passthrough reference (13,13,26)
- legacy hatch: 65, unchanged
- shell chrome bytes unchanged

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@dfattal
dfattal requested a review from a team as a code owner October 3, 2026 00:15
@dfattal
dfattal merged commit 84c7e72 into main Oct 3, 2026
40 checks passed
@dfattal
dfattal deleted the fix/macos-oop-srgb-client-content branch October 3, 2026 08:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

macOS service: _SRGB client content is one decode too dark on the shared surface (comp_multi content pass)

1 participant