Great input @Paperbot, we really appreciate your ideas! Sorry for my delayed response, got hit with the man flu.

I wrote a bit about the slider slowdown in the issue Misaki linked above (fixed in 4.3.25-beta, available now). We put reasonable effort into the editor being efficient and occasionally we do testing with huge projects to see where further improvements can be made. For this, sliders are new and were doing work that could be avoided. Still a draw order timeline with 26,000 keys is relatively slow in the editor (27fps for me). Probably don't do that.

The idea for "clear" keys is a good one! 4.3 might be a good time to get it in. We'll check how disruptive it will be to implement.

The idea for numbered animations for sliders is maybe a bit complex. We have considered allowing a slider's animation to be keyed. We even implemented it, but removed it. For sliders to work significant runtime changes were needed (that's why porting is taking a while) and this feature complicated that. The dust is mostly settled now, so maybe it could be revived. When a slider animation changes, the skeleton "update cache" has to be recomputed. That is relatively heavy, but could be OK if it doesn't happen very often (surely not 26,000 keys, right?!). The editor already does it every frame so the impact is only at runtime.

Anyway, once you can key a slider animation, then you can just use another slider and that gives you the numbered slider animations that you wanted. There is no problem that can't be solved by throwing sliders at it!

I'm scared of what a multidimensional array might mean! It is really cool seeing what people come up with, especially when it's not readily apparent even to us how they could have possibly done it.

Spine is very efficient in general because it is written like a game rather than like a typical desktop app. That allows us to not worry about performance most of the time, as the performance we get without special acrobatics is acceptable for the majority of users. This is good because optimizations can greatly complicate development. The flip side is that Spine may not scale up to what it potentially could, if it really needed to.

That said, if you run into a real world scenario where performance is an issue, please let us know and we may be able to improve it. There will always be limits that can be found with artificial scenarios, such as how many attachments can Spine handle before slowing down (IIRC 50-75k). As long as those are higher than any sane person would ever do, we're good. Eg, if you have 50k+ attachments you should probably be creating them at runtime with templates rather than rigging them all in Spine.

You can check performance in Skeleton Viewer to see how it compares to the editor. Of course you shouldn't have to suffer through a 10 FPS editor even if it's OK at runtime.

Thinking about "clear" keys, it would be pretty easy to make it a curve type. In other words, the transition between 2 keys could be set to stepped, linear, Bezier, or "clear" which would mean no change. For animations applied on top of others, this would allow the animations below to control the value. The downside is there is no transition. It would work like stepped: whatever value the animation was setting, suddenly the value from the animation below can be seen. That's OK for attachment visibility or anything else without transitions, but I expect people will want to transition smoothly to/from animations below.

To do that and keep it a curve type, we could say all clear keys are also Bezier. That's a bit hacky though. It also means you'd have some useless Bezier handles:

some keys > clear key > Bezier transition > clear key for the end of the transition > useless Bezier transition > clear key to start transition back > Bezier transition > some other keys

Otherwise, if it's not just a curve type we'd need a sort of first class key value possible for every timeline, then you'd be able to use stepped, linear, or Bezier as normal.

Or, we could make it a modifier on the curve type. So you still set stepped, linear, or Bezier but also whether it is clear. This works well with the many timelines that have curves. For the timelines that don't (attachment, draw order, event, inherit, physics reset, sequence), we'd need to do something else.

No worries, it's helpful to think through all ideas. We have no problem discard those that are too hard.

I agree a button in the dopesheet and graph may be sufficient.

After more thought, it seems hard to use the Bezier handles for the clear transition. The handles are in "value space" while the transition to or from clear is a percentage. Using the setup value as the clear value to define the transition could work, but feels a bit magical. A better way might be to have a separate timeline just for clear, though that has some complexities.

I'm now thinking maybe stepped and linear could be enough. After all, those are the only options when mixing between animations with AnimationState. Maybe clear can even be just linear, if it simplifies things.

Here's a proposal: any key can be marked as clear. The first clear key after a non-clear key is a linear transition to clear (fade out). Adjacent clear keys hold clear. The next non-clear key makes a linear transition to not clear (fade in). All keys work the same as normal -- you can still set values for clear keys, so you have the normal transition between key values and also fading in or out.

This makes clear a sort of annotation on top of the regular key system. Storing which keys are clear is easy. The difficulty of this feature is mainly what it does to the timeline logic. The next step is adding it to one timeline type and seeing how gnarly it gets.

We tried it out and I hoped to shoehorn it in with minimal changes, but ultimately it complicates the timelines a bit more than I like.

The lack of clear keys can be worked around by using multiple animations. For example, an animation played on top of other animations that does some main action, then has a few animated parts lingering for a while could be 2 animations: 1 for the main part and 1 for the lingering part. 2 animations is a bit annoying to manage, but it's possible.

There's also another way that's pretty flexible: use a slider for the part that needs to be clear. When a slider's mix is 0, its animation isn't applied at all. That means what it affects can be either keyed or clear at any time. This may come close to "playing" an animation be keying the slider frame, which so far I've been recommending against, but it could do the job. One caveat is all animations on all tracks are applied, then sliders and other constraints are applied. That means the slider animation is always on top of all animations.

Given those 3 things I think it's better not to implement clear keys. It's a neat feature but the need doesn't come up super often, has workarounds, and is a bit involved to implement. It was interesting to think through and was worth a look!

Maybe you could use one slider with each attachment keyed on a different frame? Than you'd use the slider to choose which attachment is visible, with 0 mix to clear.

I believe that is working correctly. A deform (FFD) can only be applied to 1) the mesh the deform was keyed for, or 2) any linked meshes for that mesh that have "inherit timelines" checked.

As always, we recommend not using deform keys as much as possible:
https://esotericsoftware.com/spine-keys#Deform-keys
Use bone weights to deform meshes, it's better!