I feel the current code is pretty efficient. Is there a bottleneck we can identify and changes we can make that improve that bottleneck?

Definitely avoiding submitting triangles unless the topology changed, that should speed it up (along with only submitting colour on change, or submitting colour in colors32 format, which avoids the internal unity conversion for each color (it converts from 0..1 to 0..255 or such, 4 floats at a time plus overhead per vert). When you've 300 verts on screen thats 1200 needless calculations + overhead.

That's just 10 objects with 30 verts each - sounds trivial but it's doing a LOT that it doesn't have to.

http://docs.unity3d.com/Documentation/S ... ors32.html

Same as colors, except using Color32 structure which is better for performance.

1. avoid submitting triangles at all unless topology changes (this is the most expensive operation, as each triangle has to be fed through unity's pipeline so its better not to do it unless you have to)

2. avoid submitting colors at all second most expensive thing to do - (4 times more expensive than submitting verts regardless of optimised version in link above). I know you said you wouldn't know if someone changed it or you, but I think you would, as they'd have to go through your api anyway.

For a few models this is never expensive, but being the fastest doesn't have to take too much time. It's probably a bit of an anxiety attack not knowing unity well and having so much work to do, but these changes are pretty much all you need to do.

(Along with having an option to generate normals and tangents (both optional) on a skeleton so that those guys doing lit cool looking stuff can show off spine even more without having to give the source a good kicking).

These changes sound minor, but they're really not. When you consider most of the time, sprites will all be on different frames, doing different things in a real world game, the savings on average add up really quickly. You could be doing a quarter of the cpu hog

I'm not in a rush for these optimisations, but they'll serve as a good point of reference if you need them

It may be an optimisation if users use spine throughout a large rayman style level where it's still calculating stuff off screen. In cases like this, people need to learn to cull and I'm certainly not going to be asking you to program our games for us Yes it's faster, but I doubt it's faster in most real world cases (unless targeting the lower end of mobile).

But if you have a lot of elements spread out through the level it will be faster not also set color. But then, people perhaps should be culling regardless.