Spine Playback Speed Looks Wrong? Check Both timeScale Layers

A motion previews correctly but does not run at the intended double speed in a game. Before changing the art or motion, trace whether the host and Spine runtime both scale the same time input. This article concerns an external runtime, not a newly advertised speed or timeline control in Workbench.

Identify the object that owns the multiplier

The official AnimationState.timeScale reference describes a multiplier for state-update delta, affecting animations and mixes in that state. TrackEntry.timeScale concerns one entry's animation time. They are separate layers, not interchangeable switches.

Check the installed runtime and engine component. A component may wrap another speed setting: establish which object it ultimately changes and whether the supplied delta has already been scaled. Names from different engine integrations are not automatically equivalent contracts.

Use a reproducible arithmetic record

For an ordinary forward-playing segment without queued transitions or extra time processing, think of entry advancement as incoming delta multiplied by state scale and entry scale. These are conditional arithmetic examples, not measured runtime results:

• One second supplied, state 1 and entry 2: approximately two seconds of entry time.
• One second supplied, state 0.5 and entry 2: approximately one second, because the factors cancel.
• The host doubles one second before state scale 2 and entry scale 1: approximately four seconds, not two.

One second here means an update amount converted to the runtime's required units. Do not pass a millisecond count without conversion. Log raw frame duration, converted delta and update-call count before blaming the exported images or motion.

Do not apply the multiplication to every clock

The current reference explicitly says an entry's scale does not affect mixTime. Non-default scale can also require reviewing mixDuration and queued delay. Accelerating a clip does not establish that crossfades and queue spacing shorten proportionally.

Isolate a single segment before restoring transitions and queues. Looping versus one-shot playback is another state: use the preview-loop and runtime-playback checklist instead of repeatedly resetting the animation to hide a timing issue.

Keep the acceptance evidence

1. Record export revision, runtime revision, current animation and actual entry.
2. Capture host update count, delta units and both scale factors over the same observation interval.
3. Check ordinary playback, transitions and queued playback separately, including required gameplay-event timing.
4. Restore the host's pause and time controls and confirm that two owners are not changing speed together.

Confirm assets and a motion baseline in Spine Workbench, then have the receiving project owner validate the runtime update chain. No timing or performance test of a user project was performed here; the static illustration is not speed evidence.