Open
Description
Currently, ThorVG's Lottie loader only supports image loading via base64 or file paths. In .lottie bundles, only base64 is used, since the file system is disabled to reduce bundle size. However, base64 encoding and decoding is an unnecessary step for data loading. It would be better if we could bypass this using a specific compromisation or mechanism.
Until now, here are some candidates:
- Support the global image cache from thorvg, dotlottie loads the necessary images trough the Picture, holds the handle(id), assing the value instead of the lottie image assets.
uint32_t id = Picture::load(image); //load a necessary image by a user in advance.
Picture::unload(id); //unload it after all usage by the user.
...
//in lottie asset
{
"id": "image_0",
"p": "data:image/thorvg,id" //specify the cached image id in the lottie asset. rather than base64 ver.
...
}
These are necessary ThorVG APIs for this requrements:
static uint32_t Picture::load(const char* data, uint32_t size, const char* mimeType, const char* rpath = nullptr, bool copy = false);
static Result Picture::load(uint32_t assetId);
Result Picture::load(int32_t assetId);
- Pros: Clear and safe data management using explicit IDs & A fundamental enhancement for canvas usage.
- Cons: Custom conventions ("data:image/thorvg,id") needed by dotlottie.
- Add support for Lottie asset resolver with a Callback(
asset_resolver) which is triggered by the ThorVG Lottie loader when loading image data, allowing .lottie to properly deliver the image asset throughasset_resolver.
tvg_lottie_animation_set_assets_resolver(asset_resolver, user_data);
Tvg_Result asset_resolver(Tvg_Paint* picture, const char* desired_asset, void* user_data)
{
//prepare image data and return it.
return pic->load(...);
}
- Pros: Maintains compatibility with existing tools and .lottie structure.
- Cons: Runtime behavior is more fragile, harder to debug and maintain.
Metadata
Metadata
Assignees
Type
Projects
Status
No status