macOS OOP content pass: _SRGB clients render one decode too dark (pre-existing, ADR-044 §7)

[dfattal]

macOS out-of-process (IPC / workspace) content pass: an _SRGB client is one decode too dark. Pre-existing: reproduces on v2.22.2 too, so it is not a #1799 regression. Found during the ADR-044 §7 Mac test (tmp-adr044-mac-colour).

Measured (mac box, sim_display, cube_handle_vk_macos through the workspace)

Mean luminance of the brightest 20k atlas pixels (pre-weave):

client swapchain	luminance
_SRGB (43, the default)	61 (v2.22.2: 66)
UNORM (37, DXR_SWAPCHAIN_ENCODING=unorm)	131
131 decoded once	≈57, i.e. the _SRGB client is decoded and never re-encoded

Cause

comp_multi_content_blend_draw samples the client view as its declared format (43, so the hardware decodes) into the B8G8R8A8_UNORM (44) shared-atlas render target, with no re-encode.

Fix direction

Render the content pass through the same _SRGB atlas view that #1799 adds for the workspace decorations (the atlas is now MUTABLE_FORMAT with its _SRGB sibling). Each client is then sampled as declared, blended in linear light and encoded once.

Compatibility, ADR-044 "apps first": a UNORM client holding encoded bytes currently passes through unchanged and would come out one encode lighter. Before changing it, audit which macOS clients still submit UNORM:

• the demos are on common v2.27.0 now;
• the runtime test apps;
• cube_*_macos;
• anything else.

Verification

Same atlas dump as the #1799 test. An _SRGB client should read its authored bytes (≈131 here), matching the UNORM-with-encoded-bytes reading today.

[dfattal]

Fixed by #1802 (merged as 84c7e72f5). This is the same bug as #1801, filed in parallel. Below is the "apps first" audit this issue asked for, run on the mac box.

Static audit: macOS swapchains that can reach the IPC/workspace path

Only Vulkan apps qualify, because Metal has no IPC client.

client	projection	other swapchains
gaussiansplat, released v1.29.2 and main	_SRGB (gsChooseSwapchainFormat)	—
modelviewer v0.33.0 / main	_SRGB first	—
earthview v0.11.1 / main	_SRGB first	—
avatar v0.14.2 / main	_SRGB (dxr::ChooseColorSwapchainFormat)	speech bubble: _SRGB
mediaplayer v1.13.0 / main	_SRGB (color::ChooseColorFormat)	HUD: _SRGB first
cube_handle_vk_macos, cube_zones_vk_macos, cube_hosted_legacy_vk_macos	_SRGB (dxr::ChooseColorSwapchainFormat)	cube quad probe: UNORM holding linear values (correct under the contract). Zones and strip reuse the projection format.
shell (shell-pvt #122, runtime ≥ v2.23.0)	—	all CoreGraphics surfaces _SRGB

No released macOS client writes encoded bytes into UNORM.

Live check (fixed runtime, legacy hatch as the pre-fix control)

Pre-weave atlas, sim_display. Each demo was run through the workspace twice. These are the local builds on this box, not the releases.

demo (local build)	declared	pre-fix	fixed
earthview	43	too dark (mean lum 54)	natural (116)
modelviewer	43	dark, over-saturated background (137)	correct (180)
avatar, Sep-22 local build	projection 37, bubble 37	—	brighter. Stale build: v0.14.2 declares _SRGB for both.
mediaplayer, Sep-8 local build	HUD 37, encoded bytes	correct	washed grey (one extra encode). This is exactly the ADR-044 §2 app-side case, and it only affects pre-v1.13 builds, which declare _SRGB.
gaussiansplat	43	no content	no content

Gaussiansplat: the session is active and focused, but nothing composites in either run. That is not colour related, and it should get its own issue if it reproduces on the released build.

Remaining caveat

A user with a stale local or self-built demo from before its _SRGB switch will see it washed out on the macOS workspace once v2.23.1 ships. The fix for that is to rebuild or update the demo. No runtime change is needed.

[dfattal]

Follow-up on the gaussiansplat row above: not a bug. That local build (d718fb3, Sep 22) predates displayxr-demo-gaussiansplat 7bbbb33 (ADR-041: submit every located view, alias the inactive ones). Under PRIMARY_MULTIVIEW_DXR it submitted 2 of 4 views, so every xrEndFrame was rejected (1631 XR_ERROR_VALIDATION_FAILURE). Released v1.29.2, built from its tag and run through the same macOS service, has 0 validation errors and renders normally. No issue filed.