Imagine you apply animation A then mix to animation B. B keys the head bone, but A does not. When A is being applied, the head is not affected

it may be the setup pose transform or something from a previous animation or something set programmatically. When we mix from A to B, first A is applied, then B. When A is applied, the head is not changed. When B is mixed, the head is set to what B keys. We don't have enough information to know the state of the head when B started being applied, so we can't mix between that and B.

We could make the assumption that unkeyed values use the setup pose. This is quite common, though not always what is needed (consider tracks > 0). In that case the head bone would be the setup pose during A and would mix from the setup pose to B. Also consider mixing from B to A, you might want the head to mix from B to the setup pose.

We are working on an AnimationState update for your use case. It will be a TrackEntry setting because there are many different ways people might want to apply their animations. There are many use cases, here are some brief notes on what we are considering:
http://pastebin.com/inurU03Z

Nate wrote

There are many use cases, here are some brief notes on what we are considering:
http://pastebin.com/inurU03Z

Results in: "This page has been removed!"

Weird, try this:

1
   animations:
      track 0, animation 1, keys a
      track 0, animation 2, keys b
   result: a is left in the state it was when the animation changed
      b snaps into position
   expected: a mixes back to the setup pose
      b mixes from the setup pose
   api: setting for animations to mix back to the setup pose during mix to next animation
      for the whole AnimationState? per track?
2
   animations:
      track 0, animation 1, keys attachment a
      track 1, animation 2, keys attachment b
   result: animation 1's attachment may be shown
   expected: top track attachment is shown
   api: don't use lastTime in AttachmentTimeline
      store attachment name for each slot until after animations are applied to avoid excessive skin lookups?
      if name is the same, avoid skin lookup entirely
3
   animations:
      track 0, animation 1, fires events
      track 0, animation 2
   result: animation 1 never fires events during mixing
   expected: events for previous animation can be disabled
   api: event threshold setting for what percentage of the mix events will be fired
      for the whole AnimationState? per track?
4
   animations:
      track 0, animation 1
      track 0, animation 2
      track 0, animation 3
   result: with long mix time, animation 1 disappears when animation 3 starts
   expected: all animations are mixed
   api: support mixing n animations
5
   animations:
      track 0, animation 1
      track 0, animation 2
      track 0, animation 3
   result: a small amount of time is lost at each animation change
   expected: sum of elapsed time == sum of animation durations
   api: carry over time from last animation to next
      if a single update call increments time more than an animation duration, time will still be lost
   https://github.com/EsotericSoftware/spine-runtimes/issues/154
   FIXED
6
   animations:
      track 0, animation 1
      end: track 0, animation 2
   result: calling setAnimation from end event causes stackoverflow
   expected: no crash
   api: fire end event before removing from the track, but somehow prevent it from firing again.
7
   blend back and forth between run and walk with a long mix time
      interruptions should not cause animations to snap
      solved by #4?
8
   mix over time from empty track
      useful for tracks > 0
      track 0, run animation
      track 1, raise gun to shoot should be mixed in
   currently have TrackEntry.mix but no way for it to change over time
9
   mix over time to empty track
      useful? for tracks > 0?