Sorry for late response, I was busy porting my runtime based on 4.2 spine-c to 4.3 beta spine-c.
pbk20191/spine-runtimestree/spm/4.3-beta/spine-ios/Sources
And l think, I can handle most of the case for it. But sadly I can not use extension.c / extension.h for my use case. (Maybe, lucky because in spine-cpp-lite version there was no way to exclude the symbol for spine_atlas_result, spine_event_handle etc...)
I know "spine_atlas_load_callback", but it does not matches for my use case.
the callback lacks, "name", "index", "pma", "filter-settings" which is very important for configuring and preparing texture (iOS Metal needs to handle rgba differently for pma, and CoreGraphics bitmap handles texture differently if the source was originally heif/avif compressed)
Although SpineExtension is not generally intended to be thread-safe (e.g., spine:: DebugExtension), the fact that SpineDefaultExtension is thread-safe raises some concerns in multithreaded contexts.
Specifically, I’ve observed occasional memory access warnings during testing in spine_atlas_load. I suspect—though I can’t be certain—that this might be due to some callback-related mutation happening within the function. It could very well be an issue with my test code or how I’ve implemented things, and practically speaking, since the callback function pointer is stable, it likely won’t cause a real problem. Still, it makes me a bit cautious.
Given that, we have this kind of interface:
SPINE_C_API spine_atlas* spine_atlas_load(const char* path, spine_texture_loader textureLoader, bool createTexture);
SPINE_C_API spine_atlas* spine_atlas_create(const char* data, int length, const char* dir, spine_texture_loader textureLoader, bool createTexture);
In another module, I’m using something like:
class DictionaryTextureLoader : public spine::TextureLoader;
SPINE_C_API spine_texture_loader spine_nsdictionary_texture_loader(void) {
static DictionaryTextureLoader loader;
return &loader;
}
It seems that the intended usage is for different runtime providers or consumers (like myself) to define and supply their own TextureLoader instances. While I could implement a full for loading Atlas in this pattern myself, I wonder if Spine could provide this kind of interface, making it more explicitly