Unity freezes for a long time when clicking on a SpineAnimationClip

Kitttt

After I create a SpineAnimationClip in unity timeline window, when clicking on the clip, the editor freezes for a long time. Looking at the code, it's stuck in 'SpineAnimationStateClipInspector.FindTimelineClip'. I found that there are quite a few TimelineAssets in the project, which is why it's so laggy.

However, when I went through the logic of SpineAnimationStateClipInspector, I discovered that the mixDuration setting seems to have no effect, because SpineAnimationStateClipInspector sets the mixDuration value of SpineAnimationStateBehaviour when its useBlendDuration is true, but in the GetCustomMixDuration function of SpineAnimationStateMixerBehaviour, when SpineAnimationStateBehaviour's useBlendDuration is true, it actually uses the value from TimelineClip.

Therefore, is SpineAnimationStateClipInspector useless code that can be deleted?

Harald

Kitttt After I create a SpineAnimationClip in unity timeline window, when clicking on the clip, the editor freezes for a long time. Looking at the code, it's stuck in 'SpineAnimationStateClipInspector.FindTimelineClip'. I found that there are quite a few TimelineAssets in the project, which is why it's so laggy.

Sorry for the troubles and thanks for reporting and digging into that. We will have a look at it whether we can improve the situation. Unfortunately, as Misaki mentioned, definitely not for spine-unity version 4.0, but for the recent 4.3-beta version.

Kitttt However, when I went through the logic of SpineAnimationStateClipInspector, I discovered that the mixDuration setting seems to have no effect, because SpineAnimationStateClipInspector sets the mixDuration value of SpineAnimationStateBehaviour when its useBlendDuration is true, but in the GetCustomMixDuration function of SpineAnimationStateMixerBehaviour, when SpineAnimationStateBehaviour's useBlendDuration is true, it actually uses the value from TimelineClip.

I don't quite understand how you get to this conclusion, it's not that "mixDuration setting seems to have no effect".

When useBlendDuration is enabled, the mixDuration value is ignored but the value is synced to the same value in order to:
1) be able to see in the disabled field how long the blend duration currently is
2) to have a reasonable value to start with when you later choose to disable useBlendDuration.

Kitttt Therefore, is SpineAnimationStateClipInspector useless code that can be deleted?

If you don't every use this functionality, yes, you could get away with just removing the file.

Spinebot

Based on my knowledge of the Spine Unity Timeline integration, you've identified a performance issue and a potential logic inconsistency.

Performance Issue

The freezing you're experiencing when clicking on a SpineAnimationStateClip is indeed caused by SpineAnimationStateClipInspector.FindTimelineClip searching through all TimelineAssets in your project. This can be very slow when you have many Timeline assets.

Mix Duration Logic

You're correct about the logic flow. When useBlendDuration is true (which is the default), the system uses the TimelineClip.mixDuration value rather than the value set by the inspector. This means the inspector's mix duration setting doesn't actually take effect in this case.

Recommendations

For the performance issue: You may want to report this to the Spine team or consider modifying the inspector code locally to optimize the search or cache results.
For the mix duration: If you want to control mix duration directly:
- Disable Custom Duration and Use Blend Duration on the clip
- Set your desired mix duration value
  
  When useBlendDuration is false, the system should respect the manually set mix duration value.

The inspector code does serve a purpose when useBlendDuration is disabled, but the performance issue you've identified is a valid concern that could benefit from optimization, especially in projects with many Timeline assets.

Kitttt

Spinebot But when useBlendDuration is disabled, the SpineAnimationStateClipInspector do nothing for the clip. So I think the way to optimize is to delete the entire 'SpineAnimationStateClipInspector' code

Kitttt

Package version is com.esotericsoftware.spine.timeline-4.0

Misaki

Kitttt We apologize for the inconvenience. Our Unity expert, Harald, is currently on vacation and may be able to provide more detailed advice when he returns. However, since you are using version 4.0, which is no longer updated, we cannot apply fixes to this version, even if issues are discovered.
If possible, we would appreciate it if you could test the latest version to see if the issue occurs.

Kitttt

Harald Thank you for your response. I now understand the intent behind that code. It seems that for my project, this code is indeed unnecessary. However, I still hope that there might be room for optimization in the future, even if it's in a newer version.

Harald

Kitttt We've just pushed a bugfix commit to the 4.3-beta branch which should fix the long waiting issue, tracked under this issue ticket.

A new Spine Timeline 4.3-beta UPM package is available for download:
https://esotericsoftware.com/spine-unity-download

Thanks for reporting, we hope this improves the situation in the future.