After tracking recovers, the system must decide whether to resume the frozen state or require a restart

What it is

When tracking returns from a loss, the continuous operation is frozen at the pre-loss value. The system has to pick a policy: resume—unfreeze and let the hand that is here now keep controlling from that value; or restart—drop the frozen state and require a fresh onset before continuous adjustment. Both can be right; “already frozen” does not entail either. The wrong pick looks like: the value jumps to whatever the current joint maps to as soon as the hand appears, or no amount of motion will unfreeze it.

Why it happens

Resume assumes the returning hand is still the same sender, and that mapping the current position immediately will not jump the frozen value. A common pattern is a short regrasp: the hand must approach the screen location the freeze represents, or perform an explicit pinch, before control is handed back. Restart assumes the loss was long enough that intent may have been dropped, or that the returning hand may not be the same one. Writing the current joint immediately is a worse third policy: the pose at the recovery instant overwrites a carefully tuned intermediate value. Recovery also has to handle ID swaps: if the skeleton index changed but it is spatially the same hand, resume still holds; if the index did not change but it is already another hand, resume gives control away.

Studying it

After a freeze, control loss duration, positional offset of the returning hand, and whether a different hand comes back. Compare auto-resume, approach-to-regrasp, and forced new onset. Dependent measures are jump size, wrong-takeover count, completion time, and “it jumped” reports. Split “same hand, almost where it left” from “the other side’s hand reaches in” into classes the policy must separate. Do not measure only the instant of loss; the recovery frame is this claim’s scene.

Where it stops holding

A one- or two-frame loss with the hand almost still should not force a restart; that cuts a notch in a continuous curve, and auto-resume is fitter. After several seconds, when the user has turned to speak to someone, auto-resume will pipe the next conversational gesture into the old parameter. Safety-related values often must restart with a second confirm after recovery, not quietly unfreeze. If the UI has navigated away during the freeze (another event covered the dialog), resume would act on an object the user cannot see.

Applying it

• Write a recovery policy per class of continuous operation: short loss with the hand still in place → resume; long loss or a different hand → new onset. Do not let the recovery instant overwrite the frozen value with the new position.
• Before unfreezing, offer a reversible regrasp cue (“pinch to keep adjusting”) so the user decides whether to take this slider back.
• Accept on three clips: same hand, same place, short loss → resume with no jump; same hand, large offset → require regrasp; the other hand reaching in must not inherit control.

Related

• Same group: C4.23.1 Tracking loss must be distinguished from ordinary action gaps so it is not treated as disengagement · C4.23.2 In-progress continuous operations should freeze rather than zero or cancel when tracking is lost · C4.23.4 Prolonged tracking loss should prompt the user to adjust position or lighting
• Adjacent: C4.19 Re-entry grace · C4.17 Input attribution and multi-user arbitration
• Search: resume · restart · regrasp