Turkey was fun. 🙂
hippocoder написавIn fact regarding meshes, it's very aggressively optimised on a per-device basis in the android world.
Maybe for some fancy stuff, but if we are just batching quads, black magic isn't required. 🙂 Eg, libgdx has a single code path for batching quads for OpenGL on all devices and OSes, and performance of this is faster than Unity (according to benchmarks run by others). Unity likely has more overhead when used in a similar way. It is a bit off topic why exactly it may have extra overhead, we have to deal with it either way. 🙂 I agree of course that the Spine runtime for Unity should be as optimized as possible. Unfortunately little insight is provided into what Unity does with the data it is given. It's a black box and it isn't clear what actions may be expensive. 🙁 "Profiler" is grayed out for me. I'll look into getting a version where I can use the profiler.
Currently we set the vertices, colors, uvs, and indexes ("triangles") every frame. For a Spine skeleton that is animating, we can reasonably expect every vertex to change position every frame. We use vertex colors and it is possible that these change every frame. Images for slots can be added or removed at any time. We could easily avoid setting the indices every frame, so I've committed this. I doubt it would be worthwhile to attempt to avoid setting the vertices, colors, or uvs each frame.
Collecting vertices, uvs, and colors like this is a standard way of batching for 2D games. While Unity likely causes an extra copy somewhere, I would be surprised if Unity added enough overhead to make this too slow for complex 2D games, even on mobile. Note Vector2 and Vector3 are structs.
I moved setting "renderer.sharedMaterial" so it doesn't happen every frame. That might help performance. I would love spine-unity to be able to support using an atlas with multiple pages. Do you have any insight on how a Unity mesh can use multiple materials?
hippocoder написавIt's also higher performance to keep a local copy of your verts instead of reading the verts from the structure because if you read the verts before modifying them, it will do an array copy internally first.
SkeletonComponent already keeps the vertices, colors, uvs, and indices in fields.
hippocoder написавGarbage collection hit:
AnimationStateData.cs - GetMix
KeyValuePair is a struct and will be allocated on the stack, so this method should never generate any garbage. KeyValuePair is immutable and can't be pooled. I don't think GetMix can be written any better, but it also isn't called very often, only when animations change.
hippocoder написавIt's 4ms per frame spent on just SkeletonComponent.UpdateSkeleton() and AnimationState.Apply(), which is fairly brutal for an i5. I am investigating rewriting it, but it seems tricky given I don't know the code for it. Perhaps a community project?
Those methods should already be pretty well optimized, I doubt they can be made much faster. Maybe you had a debugger attached when you were profiling? The spine-unity project is on github and I'm happy to merge contributions, so it is effectively already a community project. 🙂 We've already had 23 pull requests, most of which were merged. Using git can be a PITA, especially at first. I highly suggest SmartGit, even if you already know git.
The runtimes will continue to be maintained and improved, though for the most part the only large changes planned for the future are likely to be new features such as the event timeline and bounding boxes. If we can optimize or otherwise improve things, we'll do that by all means! Any and all help is welcome. I'm happy to discuss changes here on the forum and make them myself if we can identify improvements. If you'd like to submit pull requests via github, that would also be fantastic. 🙂 If they are merged then they will be officially maintained moving forward.
I made a few other small optimizations. Can you try with the latest and see how it performs?