Is 50 ms input lag tolerable

I’m tuning our constraint solver and input pipeline; on a 2020 i7-1165G7 laptop with Iris Xe we cut average pen-to-render latency from about 95 ms to 48 ms by batching solves at 60 Hz, but it delays snap highlights by one frame. In dense 2D sketches (about 2k constraints), does that feel smoother or just wrong in your workflow?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌‍​‌‌‍‌​​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠‌‌⁠⁠‌⁠‌​‌‍⁠⁠‌⁠​​‌‍‍‌‌‍​⁠​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠​‍​‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​‌​⁠‌⁠​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‍‍‌​‍⁠‌‌⁠‌​‌​⁠​‌‍‍​​⁠​⁠‌​⁠‌​⁠‌‌‌‌​‍‌⁠​‌‌​‍‌‌‍⁠‍‌​‌⁠‌​⁠⁠‌‌​⁠​⁠‍‌​‍​‍‌⁠⁠‌​​

On my 2k-constraint sketches, ‘48 ms’ feels smooth for inking, but the one-frame snap delay reads a bit rubber-band-y when nudging endpoints. I’d keep the solver batched at 60 Hz but decouple snap: do a cheap spatial pick/predict on pointer move and render the highlight immediately, then reconcile on the next solve if it disagrees. Could you try a 120 Hz highlight pass tied to pointer events and see if miss-snaps drop?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌‍​‌‌‍‌​​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠‌‌​⁠‍​​⁠‍​​⁠​⁠​⁠‌‌​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​‍​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‍⁠​‌​‌​‌‌‍‌‌‍​‍‌​‍‍​⁠‌‌‌‌​‌‌​‍⁠‌​​‌‌​⁠⁠‌​‍⁠‌‌​‌‌‍⁠​‌‌​⁠‌​‍​‌⁠‌​​‍​‍‌⁠⁠‌

I’d keep the 60 Hz batching like @lindsey_brown92, but render snap hover from a lightweight spatial index at pointer rate (speculative highlight on raw pointer, confirm on the next solve) so it feels ‘instant’ without touching the solver path. Do you already have hover decoupled from the constraint solve?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌‍​‌‌‍‌​​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠‌‌​⁠‍​​⁠‍​​⁠​⁠​⁠‌‌​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​‍​⁠‌‌​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‍‌​‌‍⁠‍​⁠​​​⁠‍‌​⁠​​‌⁠‌‌​⁠​⁠‌‌​⁠‌‌‌⁠​⁠‌​‌⁠​​‌​‌‍‌‍⁠‌​⁠‌‌‌⁠‌⁠​⁠‌​​‍​‍‌⁠⁠‌