- 已编辑
Blog post: Upcoming views, sneak peek
Wow I really like Metrics view.
Since we have complex characters, and at the same time we can show 20 different skeletons in the game. we really need to optimize all
So usually we check data file for its size, if it is less then 50kb then it is ok now we can see what is overused in metrics view.
Would like to see what would be data size(in kb) in editor 
The size of the data file doesn't affect drawing performance. The best metrics are bones, vertex transforms, timelines (all three are an indication for CPU usage) and area (indication for GPU fill rate).
16 天 后
We had problems with overusing heap space, so JSON could not be parsed. after reducing the file size for each character in the stage for 70% everything went fine.
By the way do meshes affect on GPU performance more than simple regions.
- 已编辑
It was overusing the heap at load time? In what platform?
Meshes (especially with weights and FFD) affect CPU performance more than GPU. But it really depends on complexity. Having several extra vertices for a few attachments versus having many overlapping RegionAttachments, can actually be faster. And only having those extra vertices won't noticeably cost you, and can be well worth it for main characters.
Meshes actually help performance with images that cover large parts of the screen: you can cut out transparent parts which helps reduce its cost in terms of GPU fill rate.
We used Java (with libGDX) to develop games on android devices.
And yes the game was crashing at load time.
Did you send the old version of that .json/data file to esoteric software?
Maybe it could have helped so they could put warnings or something in Spine editor to inform users of things they can remove from animations to make them smaller (and not cause their game to crash).
Weird that JSON parsing was taking so much memory. I wrote the JSON parser for libgdx, though it was designed for ease of use, not to be efficient. Use the binary format to be efficient, parsing that has almost zero overhead.