A universal, high-performance Lottie and dotLottie player built with Rust. Offers smooth rendering across platforms, low resource consumption, and extensive compatibility. Features FFI bindings for C/C++, Kotlin, Swift, and WASM for seamless integration in Android, iOS, and Web projects.
We are currently storing both the dotLottie file buffer and the deflated Lottie JSONs in memory. This approach results in double the memory consumption, which is inefficient, especially when working with large animations or in resource-constrained environments.
Short-term solution:
Cache all the assets in the provided dotLottie file and then remove the dotLottie file from memory. This approach should work well for users who are using a single animation dotLottie file and do not require themes or state machines in the future. This is the most common use case for the majority of users since the creation tools on LottieFiles do not yet support multiple dotLottie animations, theming, or state machines.
Long-term solution:
Implement inversion of control by allowing users to provide a list of assets they want to cache upfront, which they may or may not use in the future during load time. This would enable users to optimize scenarios where they might use a single or a few assets on one platform but a different set of assets on another platform.
We are currently storing both the dotLottie file buffer and the deflated Lottie JSONs in memory. This approach results in double the memory consumption, which is inefficient, especially when working with large animations or in resource-constrained environments.
Short-term solution: Cache all the assets in the provided dotLottie file and then remove the dotLottie file from memory. This approach should work well for users who are using a single animation dotLottie file and do not require themes or state machines in the future. This is the most common use case for the majority of users since the creation tools on LottieFiles do not yet support multiple dotLottie animations, theming, or state machines.
Long-term solution: Implement inversion of control by allowing users to provide a list of assets they want to cache upfront, which they may or may not use in the future during load time. This would enable users to optimize scenarios where they might use a single or a few assets on one platform but a different set of assets on another platform.
Related issue: https://github.com/LottieFiles/dotlottie-ios/issues/33