runtime(zones,#804): D3D11-service published wish goes binary - #808
Merged
Conversation
…er never enters the wish Service leg of the #801/#803 backend-parity port. The standalone wish-over-IPC publish still rastered the union-of-zone-rects mask with the old implicit 16px ring feather (8 steps x 2px), which leaked cosmetic fractional M into the hardware-facing wish the per-client DP samples (fuzzy weave-vs-crisp-2D edges at zone boundaries, pre-#800 semantics). Per #800/#801 (ADR-027: the wish is HARDWARE-only, hard-edged by default): - service_update_zone_wish_mask now rasters BINARY (M=1 per zone rect via one ClearView, 0 outside) - no rings, no per-zone inset clamp needed. - One-shot log keeps the greppable mode tag (mode=zones-binary-wish). Scope notes (from code inspection, recorded on #804): - The service has NO compositor-side weave-vs-2D lerp - zones visuals are the pre-weave per-view atlas blits, where Local2D already composites by alpha (the VK invisible-toast bug never existed here), so #801's MODE_ZONES composite has no service counterpart. - #803's XrDisplayZoneFeatherDXR is a composite cosmetic and never enters the wish, so a feather request is a documented no-op on this path (a feathered service composite would need a second, non-wish mask channel through the DP vtable - out of scope). - Workspace mode is untouched (wish INERT, ADR-027 v1); the visible delta is standalone zones clients' zone edges going hard at the DP lerp. Refs #800, #801, #803. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This was referenced Jul 27, 2026
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.
Service leg of the #801/#803 backend-parity port (#804, leg 1 of the ordered plan: D3D11-service first, then in-proc D3D11/D3D12, Metal, GL).
What
service_update_zone_wish_maskstill rastered the per-client published wish with the old implicit 16px ring feather. Per #800/#801 (ADR-027: the wish is HARDWARE-only, hard by default), the raster is now binary — M=1 per zone rect, 0 outside. One-shot log keeps a greppable mode tag (mode=zones-binary-wish).Why nothing else changes on this path
From code inspection (details in the #804 comment):
Expected hardware delta
Standalone (non-workspace) zones clients over IPC: zone weave-vs-crisp-2D edges go hard at the DP lerp. Shell/workspace scenarios: expected pixel-identical (wish inert) — the #804 regression matrix (Unity tile, Unreal, Local2D chrome over engine tiles, cube_handle_d3d11_win control) still needs the usual eyeball pass.
Refs #800 #801 #803 #804.
🤖 Generated with Claude Code