We would need to see your texture packer settings to give feedback on why it is not packed in a smaller total image size.

In general, texture packing tries to pack into a given size so that all the items fit. It does not necessarily try to pack them as tightly as possible within the given size. That means if you tell it to pack into a size larger than needed, the image regions may be spread out. The only thing that matters is they all fit.

Spine's texture packer allows you to specify a minimum and maximum size. It then tries packing at small sizes first. If the regions don't fit, it tries increasingly larger sizes until they fit. This is how it finds the smallest size that fits everything tightly, but it takes a lot more time. If you start with a larger size, or even a fixed size where the minimum and maximum are the same, then packing can be done more quickly, but it may not be the smallest possible size.

You can get faster packing by checking Fast, which makes Spine not try as hard to find the optimal packing. In 4.3 Fast is much faster and the packing quality is much better than < 4.3.

Ah, I see. It's the same reason though. Packing algorithms try to fit everything in the space you provide. Doing that is hard enough (packing is NP困难 which means a solution can only be a "reasonable try") without trying to minimize blank space. At runtime, without compression, generally the memory used by an image is width * height * 4 bytes. It does not matter how much of the image is blank, it takes up the same memory, it only matters if you can fit all your regions.

@mingjava Note that you can specify the output texture size of skin.GetRepackedSkin() via the maxAtlasSize parameter in spine-unity. Unfortunately when specifying a too large size like 2048x2048 while it would fit in 1024x1024 seems to just leave more space blank instead of returning a smaller texture. Packing is performed via Unity's Texture2D.PackTextures(), so without rather costly post-packing analysis, we unfortunately can't do much about it I'm afraid.