Found while wiring displayxr-common v2.24.0's grid provider (PR #1725). Until a present-owner client has submitted its first frame, xrWeaveSnapWindowGridDXR reports declined (the engine has no viewing distance yet), but xrWeaveSnapWindowRectDXR cannot express a decline and returns success with the position unchanged. displayxr-common's helper then falls back to the per-point path and builds an all-allowed table with 16,641 IPC calls and no snapping. Real drags start long after the first frame, so this is a consistency bug, not a user-visible one today. Fix: make the per-point route report the same decline (spec-wise xrWeaveSnapWindowRectDXR returns XR_SUCCESS with snapped = XR_FALSE; the helper should treat that as decline too), or have the grid call return identity-without-decline in the same pre-frame state, so both routes agree. Part of #1699 / #1723.
Found while wiring displayxr-common v2.24.0's grid provider (PR #1725). Until a present-owner client has submitted its first frame,
xrWeaveSnapWindowGridDXRreportsdeclined(the engine has no viewing distance yet), butxrWeaveSnapWindowRectDXRcannot express a decline and returns success with the position unchanged. displayxr-common's helper then falls back to the per-point path and builds an all-allowed table with 16,641 IPC calls and no snapping. Real drags start long after the first frame, so this is a consistency bug, not a user-visible one today. Fix: make the per-point route report the same decline (spec-wisexrWeaveSnapWindowRectDXRreturnsXR_SUCCESSwithsnapped = XR_FALSE; the helper should treat that as decline too), or have the grid call return identity-without-decline in the same pre-frame state, so both routes agree. Part of #1699 / #1723.