GamerXP Also, I was profiling the project yesterday and SkeletonMecanim component were taking quite a lot of performance (around 25% of whole load with 7 skeletons).
First and foremost it depends on the complexity of your skeletons. If you have only 7 skeletons active, it sounds as if these might benefit from some optimizations on the Spine project side first:
https://esotericsoftware.com/spine-unity-faq#Performance
What are the current metrics of your skeletons? Is both Update and LateUpdate equally large? Also be sure to disable Deep Profiling, otherwise the numbers will be highly distorted.
Do you think it can be optimized by using Unity's job system + burst compiler?
Unfortunately that's not really feasible. The problem is that both require all data setup as plain structs.
As the Spine core runtime is laid out in a different way, it's not really feasible to transfer the full feature set to structs in the near future, it would require a whole rewrite of the core runtime in DoD fashion.
There was a thirdparty asset available on the Asset Store in the past which mapped the most basic Spine functionality to ECS and Tiny:
https://assetstore.unity.com/packages/tools/animation/spine-animation-converter-for-ecs-and-tiny-181832
Unfortunately it has been discontinued. If you're really interested, you might be able to ask the seller (UnnyNet) if he still sells or shares the package upon request.
What we currently have in the making (see this issue ticket) is parallelization using normal threads. In our tests this cut down processing time of both processing animations (Update) and mesh generation (LateUpdate) on a quad-core machine to roughly a third. We're not done yet though, as the whole feature set (especially callbacks) needs some more adaptations to be safely usable in the parallelized environment, with as little change of the user code as possible.
(I've optimized it for now by disabling updating when not visible)
I'm not sure if you've implemented your own means of detecting that, but please note that there is already the Advanced - Update When Invisible component property available for this purpose.
And what do you think about using 2D animation package's methods? I've looked into it a bit more. Basically, they send vertex deformation data to SpriteRenderer components using internal methods.
What do you have in mind, what do you think would be beneficial of the 2D animation package? If you mean to utilize GPU skinning: we don't need the 2D animation package for that. We've considered implementing GPU skinning in the past, but as it would only cover a very limited subset of the Spine features, we've discarded the idea. Note that for GPU skinning to work, you need to have a fixed mesh and only classic weighed skeletal animation, so you could e.g. not change attachments or use mesh deformation animation (vertex animation).
If you meant something else, please do let me know.
There are some ways to access internal APIs without reflection, like Assembly Definition Reference. In theory, should be possible I think?
Using reflection would not be a problem.
If we combine sprite atlases, 2D animation API and Job system - Spine runtime's performance will skyrocket.
Using Unity's Sprite Atlases brings no performance benefit. You can already use Spine's texture packer which will pack polygons more tightly, knowing the shape of the mesh attachment. So this would in theory make it slightly worse.
