iOS SDK - SpineView using up a lot of memory?

solidcubes

Hi, I'm currently using the official Spine iOS SDK in my SwiftUI app and would like to ask about the following:

My spine assets (.skel, .atlas and .pngs) are ~40mb which I use to instantiate the SkeletonDrawableWrapper, but when I present them using SpineView, memory usage for my app climbs up to around _1GB. The exact numbers are not as important, more so I was wondering what could be causing this spike in memory usage.

Not sure if this helps any, but when I try profiling with Instruments it shows the system libraries (specifically Metal? IOGPUResourceCreate and mmap) producing that memory spike.

As a follow up, is there a way to selectively load textures/assets into memory when instantiating the SpineModel/SpineView? From my understanding everything is loaded? Sorry, I'm not an expert in Spine.

Please let me know if you need more details, thank you!

Spinebot

The memory spike you're experiencing when using the Spine iOS SDK could be due to several factors. One possibility is that all textures and assets are being loaded into memory at once, which can be quite demanding, especially if your assets are large. This is consistent with the behavior of the Metal library, which is responsible for rendering and can consume significant memory resources when handling large textures.

To address this, you might consider implementing a strategy to load only the necessary textures and assets into memory. This can be done by dynamically loading and unloading assets based on what is currently needed for rendering. This approach is mentioned in the context of managing a large number of attachments, where it's suggested to pack an atlas at runtime containing only the images needed for the current scene or level. This way, you can minimize the memory footprint by only using video memory for the attachments you are going to render.

Additionally, you might want to explore optimizing your texture atlases to ensure they are as efficient as possible, potentially reducing their size or the number of textures being used at any one time.

solidcubes

Following up, I made a minimum reproducible app:

import SwiftUI
import Spine

struct ContentView: View {
    @State var model = SpineModel()
    
    var body: some View {
        Group {
            if model.isReady, let drawable = model.drawable {
                SpineView(
                    from: .drawable(drawable),
                    controller: model.controller
                )
            } else {
                Text("Loading SpineModel...")
            }
        }
        .task {
            await model.retrieveSpineAssetsLocally()
        }
    }
}

@Observable final class SpineModel {
    var controller: SpineController
    var drawable: SkeletonDrawableWrapper?
    
    var isReady: Bool = false
    
    init() {
        controller = SpineController(
            onInitialized: { controller in
                controller.animationStateData.defaultMix = 0.2
                controller.animationState.setAnimationByName(
                    trackIndex: 0,
                    animationName: "exampleAnimation",
                    loop: true
                )
            },
            disposeDrawableOnDeInit: false
        )
    }
    
    @MainActor
    func retrieveSpineAssetsLocally() async {
        isReady = false
        do {
            let drawable = try await SkeletonDrawableWrapper.fromBundle(
                atlasFileName: "myAtlas.atlas",
                skeletonFileName: "mySkel.skel"
            )
            self.drawable = drawable
        } catch {
            // Should never reach here when debugging locally.
            fatalError("No bundled Spine assets found.")
        }
        isReady = true
    }
}

which reports an idle memory usage of _1.2GB in Xcode on my real device.

Strangely enough, when using the Simulator (iPhone 16 on iOS 18.2, Rosetta version), the app hovers around only 200mb.

And profiled simply using the Allocations tool in Xcode Instruments:

solidcubes

Sorry for not keeping it all in one thread, keep wanting to add more info.

The Instruments screenshot above is for the real device. Here is the one for the simulator:

I notice that both VM: IOAccelerator or VM: IOSurface is not present in the Statistics table view in the Instruments screenshot for the Simulator. Not sure if that helps any.

Nate

My spine assets (.skel, .atlas and .pngs) are _40mb

What are the resolutions of your PNGs? A 2048x2048 PNG can be relatively small when compressed on disk, but uncompressed takes 2048 * 2048 * 4 = 67.1MB. It's width * height * 4 bytes for RGBA (32 bits per pixel). 40MB of PNG (which is always compressed) can be quite a lot uncompressed.

solidcubes

The pngs vary in res, but they're below 2048x2048 (maybe like 600x1000, 600x500 etc.). While there are a lot of pngs, I only use a few at a time. Is there support for selective texture loading of any kind, in the SDK or Metal, or is that something to be done manually? Any advice/ideas would be appreciated

Nate

By default loading an atlas loads all the PNGs. Our APIs are flexible and texture loading can be selective or delayed, but I'm not sure how best to do that for the spine-ios runtime. My colleague Mario is out until next week, but he will be able to help them. Sorry for the delay! In the meantime it might help to try with an atlas containing only the PNGs you need, then see how memory usage changes.