• Editor

  • Slot per image for PNG sequence, performance impact.

    anglais
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!