Seen by David on the two-panel win rig (2026-10-09, runtime main after #1880, D3D11): with cube_handle_d3d11_win straddling the laptop panel and the DS1, while the window is being dragged a small strip of one half's content shows up on the other panel's side of the seam; it recovers as soon as the drag stops. The hand-offs themselves were clean (nine hand-offs in his drag session, 5–13 ms each, no black frame).
Likely cause: the segment table is computed from the window rect the compositor read for this frame while the weave consumes the egress slot that is one frame behind (the #918 split path, ADR-047 Amendment 1: "a split egress slot one frame behind a resizing window still partitions its tile with the seam where the live window puts it"). During a drag the seam column moves every frame, so the previous frame's atlas is partitioned at the new seam: a few px of the DS1 segment's views are woven by the laptop DP (or vice versa) until the window rests. Same class as the move-sync problem solved on Linux (runtime #1856, PR 447 move sync) — the Windows in-process path has no move/content sync.
Options: (a) partition with the rect the egress frame was rendered at (carry the window rect with the slot), accepting that the weave lags the window by one frame during a drag; (b) a one-frame hold of the previous table while dragging; (c) a Windows move-sync like the Linux one. Needs an eyeball on the rig after the change; the log cannot see it.
Seen by David on the two-panel
winrig (2026-10-09, runtime main after #1880, D3D11): withcube_handle_d3d11_winstraddling the laptop panel and the DS1, while the window is being dragged a small strip of one half's content shows up on the other panel's side of the seam; it recovers as soon as the drag stops. The hand-offs themselves were clean (nine hand-offs in his drag session, 5–13 ms each, no black frame).Likely cause: the segment table is computed from the window rect the compositor read for this frame while the weave consumes the egress slot that is one frame behind (the #918 split path, ADR-047 Amendment 1: "a split egress slot one frame behind a resizing window still partitions its tile with the seam where the live window puts it"). During a drag the seam column moves every frame, so the previous frame's atlas is partitioned at the new seam: a few px of the DS1 segment's views are woven by the laptop DP (or vice versa) until the window rests. Same class as the move-sync problem solved on Linux (runtime #1856, PR 447 move sync) — the Windows in-process path has no move/content sync.
Options: (a) partition with the rect the egress frame was rendered at (carry the window rect with the slot), accepting that the weave lags the window by one frame during a drag; (b) a one-frame hold of the previous table while dragging; (c) a Windows move-sync like the Linux one. Needs an eyeball on the rig after the change; the log cannot see it.