fix(metal): blend window-space layers instead of overwriting (#1788)

[dfattal]

Fixes #1788

Problem

The Metal compositor's window-space pass (XrCompositionLayerWindowSpaceDXR) bound projection_pipeline, which has blending disabled. A window-space HUD therefore overwrote its whole rectangle in the atlas, colour and alpha both, instead of compositing over the 3D content. Every other backend blends here: D3D11/D3D12, and vk_native and GL as of #1787.

Fix

The window-space draw now picks a blended pipeline per layer, using the same rule as the other backends:

	colour src	colour dst	alpha src	alpha dst
SOURCE_ALPHA_BIT clear (premultiplied)	ONE	ONE_MINUS_SOURCE_ALPHA	ONE	ONE_MINUS_SOURCE_ALPHA
SOURCE_ALPHA_BIT set (straight)	SOURCE_ALPHA	ONE_MINUS_SOURCE_ALPHA	ONE	ONE_MINUS_SOURCE_ALPHA

The alpha "over" keeps atlas alpha intact for transparent sessions (#225/#1784). proj_premult_pipeline and proj_straight_pipeline already exist with exactly these factors, and they use the same projection shaders and Depth32Float attachment that the window-space pass already used. So this change only swaps which pipeline is bound and creates no new pipeline state.

• projection_pipeline is unchanged: its REPLACE is what the base blit relies on (DP compose-under-bg likely applied per-layer instead of post-composite — desktop bleeds through semi-transparent window-space HUD over opaque content #225/CTS composition: projection layers are blitted opaque over the whole tile, wiping every layer submitted before them (QuadProjectionQuad / ProjectionQuadProjection FAIL) #1598).
• The pipeline is chosen directly from the layer flags, deliberately not through comp_layer_blend_mode() (CTS composition: quad with UNPREMULTIPLIED_ALPHA and no SOURCE_ALPHA flag (alpha=0 texture) is drawn far too bright instead of opaque — SourceAlphaBlending FAIL #1599). The reason is in the comment at D3D11's window-space draw.
• This is the only window-space draw site in src/xrt/compositor/metal/. The shared-texture (_texture) Metal path goes through the same metal_compositor_layer_commit pass. The other window-space consumers (compositor/multi/*) are Vulkan code and out of scope here.

Testing (macOS)

Test setup: cube_handle_metal_macos, sim_display anaglyph, /tmp/dxr_atlas_trigger atlas capture. The HUD was forced visible by a temporary local-only edit, which is not in this PR. A/B on the same build tree:

• Before (main): the HUD is a solid grey rectangle that hides the grid lines behind it. With DXR_ATLAS_CAPTURE_RAW_ALPHA=1, the HUD region writes atlas alpha down to 128 over opaque content. That is the DP compose-under-bg likely applied per-layer instead of post-composite — desktop bleeds through semi-transparent window-space HUD over opaque content #225-class bleed, where the DP would show the desktop through the HUD.
• After, straight path (the HUD's real flag, SOURCE_ALPHA_BIT): the panel is translucent, the grid shows through, and there is no hard rectangle. Raw atlas alpha in the HUD region is 255 everywhere, so destination alpha is preserved.
• After, premultiplied path (flags temporarily flipped to 0 in the build-dir copy of displayxr-common): translucent, with crisp text, no halo and no darkening. Atlas alpha is 255.

Not tested

• Real Leia or other vendor weaving on macOS. Only sim_display anaglyph was tested; the check is atlas pixels before the DP.
• A transparent-background session (DISPLAYXR_TRANSPARENT_BG) where the atlas starts with alpha < 1 under the HUD.
• The _texture Metal apps (cube_zones_texture_metal_macos) and the hosted/legacy Metal apps. They share the same draw site but were not run.
• A window-space layer with a non-zero disparity, and multiple window-space layers.
• Not run through clang-format: src/xrt/.clang-format has no Objective-C section, so the tool refuses .m files. Style was matched by hand.

🤖 Generated with Claude Code