• Editor
  • Slot per image for PNG sequence, performance impact.

  • Изменено
Related Discussions
...

Performance impact of having several slots

I'm wondering if there are any performance implications for png sequences in this scenario. When I drag and drop the sequence on a bone, Spine creates a slot per image. When I drag the sequence onto a slot, they all attach to that single slot.

Some games I work on can have rather large png sequences embedded (15-20+ frames, and multiple sequences) in a spine skeleton. Should I recommend to our spine artist to group them under one slot or use the spine default behavior where 1 slot for each image.

Thank you!

Look at the skeleton rendering:
https://github.com/EsotericSoftware/spine-runtimes/blob/4.0/spine-libgdx/spine-libgdx/src/com/esotericsoftware/spine/SkeletonRenderer.java#L92
For each slot, it checks the attachment and renders it if needed. If you have many slots, there are more to check. That is unlikely to be a bottleneck in your app.

However, slots are better for organization. If you ever only show at once only attachment from a logical group of attachments, it makes sense to put those attachments under the same slot.

Note in 4.1 you can check Sequence on a region or mesh attachment, then you can play a frame-by-frame sequence without creating an attachment per frame.

Good to know it's still not much of a concern performance wise. I agree on the organization benefits. Looking forward to us upgrading to 4.0 in the near future.

Thanks much Nate!