Suggestion: Merge with lottie-flutter about fluttie HOT 4 OPEN

My fork of Lottie Flutter renders a good number of Lottie files correctly, however, I wouldn't quite regard it as production ready, for at least the following reasons:

• I'm pretty sure there are issues with the widget structure wrt probably needing to be a little more sophisticated than just using a CustomPaint class.
• We're not really caching any of the data we parse, and parsing is all pretty tightly coupled to rendering so it makes it hard to do that.
• There is no implementation around fetching images for rendering (I'm pretty sure Android supports that, but not 100%).

I want to see Lottie work on Flutter, but I'm leaning more towards piecing together a solution involving more direct Skia usage than this - but there's a bigger backstory to make that work. That said, if you'd like to somehow merge these efforts I have nothing against that either.

from fluttie.

I also just realized that this fork already implements everything except for dashed paths, but also has dashed paths checked in it's todo list. @dnfield Can you please clarify whether that feature is already available?
If it has feature-parity with the official Lottie for Android implementation, I'll try to figure out if I can turn this library into some abstraction layer that uses lottie-flutter internally so that existing users don't have to migrate their usages.

from fluttie.

fabiomsr/lottie-flutter#6

from fluttie.

Hey, thanks for the suggestion.
The scope of lottie-flutter is way bigger than the one of this repository: This one only works on Android and just pipes the output of the regular Lottie-Android library into a texture that is then displayed by Flutter. The lottie-flutter library (as far as I know) however is aiming at implementing lottie entirely in Dart, thus making it available on all platforms, having more control over how the animation will be shown and being more integrated with other Flutter widgets. The downside (at the moment, according to their readme) seems to be that some Skia APIs that would be needed aren't available to Dart yet and that the library doesn't support all Lottie features yet.
Looking at these two approaches that are radically different from each other, I think that of the lottie-flutter library, once it's more polished, will be the best one to use, especially considering multi-platform availability. Personally, the main reason I started this library was that lottie-flutter didn't seem usable at that point and I didn't need iOS support. I don't know the current state of that project, but I think in the long-term, the best approach is to only use lottie-flutter and deprecate this library.

Long story short: Given that the implementation is completely different, merging both together doesn't seem beneficial to me. However, I'll watch this issue and the one on lottie-flutter and see if there are any good points that speak in favor of merging them together in the near-future. If it turns out to be a good idea, I certainly wouldn't mind it and would be glad to help in that process.

from fluttie.