sky_line/Slipstream

Fork 1

Click-and-hold touch objects update ~2x per second (e.g. a head petter's hoof following the mouse) #837

New issue

Closed

opened 2026-10-18 02:06:44 +00:00 by sky_line · 2 comments

sky_line commented

2026-10-18 02:06:44 +00:00

Owner

Scripted objects that follow the mouse while you click and hold update at roughly 2 times per second instead of at frame rate.

Test case: a head petter that, while you hold the mouse button on it, spawns a small hoof under the cursor that follows the mouse. The hoof jumps along in steps about half a second apart instead of tracking smoothly.

Seen on the 1.3 development build (1fe80328d5, the beta 13 code + fixes).

Two halves to separate

The hoof's position goes cursor -> viewer ObjectGrabUpdate (touch position / UV / ST from the pick) -> sim -> script moves the hoof prim -> sim ObjectUpdate -> viewer draws the prim at its new position. Either end could be the slow one.

Viewer send rate. LLToolGrabBase::handleHoverNonPhysical (lltoolgrab.cpp) sends an ObjectGrabUpdate only when the pick's surface data or grab position changed since the last message.
- Check whether the surface info is refreshed every hover frame. The pick comes from mGrabPick plus getSurfaceInfo(); pickAsync runs at mouse-down.
- Measure: enable RenderVKTouchDiag (it logs every grab message's SurfaceInfo) and count ObjectGrabUpdate lines per second while dragging. About the frame rate means the viewer is fine; about 2 per second means it's here.
Render update rate of moved prims. If the viewer sends at frame rate, check how quickly a prim moved by a script (llSetPos / llSetLinkPrimitiveParamsFast) is redrawn after its ObjectUpdate arrives. The instance / transform upload of non-physical moving objects might be throttled or batched. Test with a prim moved on a fast timer (e.g. 10-20 Hz) and compare with the incoming update rate.

Also compare with another viewer if possible: scripted movement is capped by the sim's own update rate, so the target is "as fast as the sim sends updates", not necessarily frame rate.

Scripted objects that follow the mouse while you click and hold update at roughly **2 times per second** instead of at frame rate. **Test case:** a head petter that, while you hold the mouse button on it, spawns a small hoof under the cursor that follows the mouse. The hoof jumps along in steps about half a second apart instead of tracking smoothly. Seen on the 1.3 development build (1fe80328d5, the beta 13 code + fixes). ### Two halves to separate The hoof's position goes cursor -> viewer `ObjectGrabUpdate` (touch position / UV / ST from the pick) -> sim -> script moves the hoof prim -> sim `ObjectUpdate` -> viewer draws the prim at its new position. Either end could be the slow one. 1. **Viewer send rate.** `LLToolGrabBase::handleHoverNonPhysical` (`lltoolgrab.cpp`) sends an `ObjectGrabUpdate` only when the pick's surface data or grab position changed since the last message. - Check whether the surface info is refreshed every hover frame. The pick comes from `mGrabPick` plus `getSurfaceInfo()`; `pickAsync` runs at mouse-down. - Measure: enable `RenderVKTouchDiag` (it logs every grab message's SurfaceInfo) and count `ObjectGrabUpdate` lines per second while dragging. About the frame rate means the viewer is fine; about 2 per second means it's here. 2. **Render update rate of moved prims.** If the viewer sends at frame rate, check how quickly a prim moved by a script (`llSetPos` / `llSetLinkPrimitiveParamsFast`) is redrawn after its `ObjectUpdate` arrives. The instance / transform upload of non-physical moving objects might be throttled or batched. Test with a prim moved on a fast timer (e.g. 10-20 Hz) and compare with the incoming update rate. Also compare with another viewer if possible: scripted movement is capped by the sim's own update rate, so the target is "as fast as the sim sends updates", not necessarily frame rate.

sky_line added the

bug

status

up-next

labels

2026-10-18 02:06:44 +00:00

sky_line added this to the Slipstream project

2026-10-18 02:06:44 +00:00

sky_line added

and removed

labels

2026-10-18 02:11:53 +00:00

sky_line commented

2026-10-18 02:46:42 +00:00

Author

Owner

Fixed on release/1.3 (4336785b5e), also on the dev branch. Root cause: while a grab was held, the cursor pick's surface cache re-served its own previous answer for ~32 frames (~0.5 s), so the grab's UV/ST/position stayed frozen and ObjectGrabUpdate (sent only on change) went out about twice a second. The cache is now reused only for a fresh pick at the same pixel. RenderVKTouchDiag logs the ObjectGrabUpdate rate once a second. Owner verified with a head petter: the hoof tracks smoothly.

Fixed on release/1.3 (4336785b5e), also on the dev branch. Root cause: while a grab was held, the cursor pick's surface cache re-served its own previous answer for ~32 frames (~0.5 s), so the grab's UV/ST/position stayed frozen and ObjectGrabUpdate (sent only on change) went out about twice a second. The cache is now reused only for a fresh pick at the same pixel. RenderVKTouchDiag logs the ObjectGrabUpdate rate once a second. Owner verified with a head petter: the hoof tracks smoothly.

sky_line added

and removed

labels

2026-10-18 02:46:42 +00:00

sky_line referenced this issue from a commit

2026-10-18 02:46:43 +00:00

#837: held-grab touch data frozen ~0.5 s by the pick's self-served surface cache

sky_line referenced this issue from a commit

2026-10-18 20:11:53 +00:00

#837: held-grab touch data frozen ~0.5 s by the pick's self-served surface cache

sky_line commented

2026-10-18 22:26:30 +00:00

Author

Owner

Fixed in Slipstream 1.3.0 (stable): https://git.slipstreamviewer.org/sky_line/Slipstream/releases/tag/v1.3.0

If you still see this on 1.3.0, reply here and we'll reopen it.

Fixed in **Slipstream 1.3.0** (stable): https://git.slipstreamviewer.org/sky_line/Slipstream/releases/tag/v1.3.0 If you still see this on 1.3.0, reply here and we'll reopen it.

sky_line closed this issue

2026-10-18 22:26:31 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sky_line/Slipstream#837

No description provided.

Rows
Columns