Hey! If I understand correctly, Compose Desktop uses https://github.com/JetBrains/skiko which in turn uses https://github.com/JetBrains/skija (a library that provides java bindings for https://skia.org/). And Skia is an actual rendering library. I’m asking because I recently contributed Skottie (https://skia.org/user/modules/skottie) bindings to Skija. If my understanding is correct then Compose Desktop doesn’t expose Skija in public API so it’s not possible to create a 3rd party library for playing Lottie animations. I’m thinking about contributing something similar to: http://airbnb.io/lottie/#/android-compose directly to Compose Desktop. But before I pull the Compose repo and start learning its tooling, I wanted to ask if you think it’s a good idea and if my understanding is correct.

Your summary sounds correct to me. I think the Skija bindings are not directly exposed but IIRC the Skiko bindings are exposed, so I think you'd just need a corresponding CL to the skiko repository? And then the rest could be done via a 3rd party library I think?

Interesting. If it would be possible to somehow use Skija as an external library then I could make a PR to Airbnb Lottie library to have all Lottie stuff in one place. I was focusing on Skottie bindings for Skija so far and I haven’t looked at other parts much yet. What would be the best way to do this in your opinion (assuming today’s state of Compose Desktop)?

At second glance, it looks like Compose is using more of the skija APIs more directly than I would have expected. IIUC, we're going to want to move everything over to skiko and hide skija a bit more, but I suppose that's just uncompleted work at this point, and we're just using skija directly because it's the more expedient thing to do. You could probably do the same, and move to skiko at some point in the future when it is more built out. Is Lottie using

androidx.compose.ui.graphics.Canvas

or

androidx.compose.ui.graphics.AndroidCanvas

or

android.graphics.Canvas

? If the third, probably worth migrating it to the second. If the second, it would be interesting to see what the second provides that isn't provided by the first. I think

DesktopCanvas

is pretty similar to

AndroidCanvas

in terms of capabilities, and both basically just delegate to their respective underlying implementations, so it seems like it would be very feasable to do with only minor additions to

DesktopCanvas

. The above is all subject to corrections from @olonho; he is the subject matter expert on all this, so I'll defer to him.

Pinging @gpeal as well, he is the author of Lottie Android

It's using the third. Right now,

lottie-compose

just wraps

LottieDrawable

from

lottie-android

Yes considering that lottie is built with public Android canvas APIs and compose provides a wrapper, ideally a desktop equivalent of lottie would be built with desktop compose canvas APIs since we expose a similar set of functionality. I don't think you would need modify skija do this as long as the underlying drawing primitives are there.

Skia bindings are available on desktop and could be used, if needed.

FWIW, according to my experience the Compose Canvas is (still?) missing several features compared to its native counterparts. In my experiments this forced me to go native several times.

What are those missing features?

@olonho E.g., it does not seem to be possible to draw an image onto the canvas and specify the source and target bounds via floating point coordinates. Imagine you have scaled your drawing area to an interval 0.0 to 1.0. How would you place a small image in there if you only have integer coordinates? There is a reason why the native Canvases all provide this option. Another issue is the missing method

drawBitmapMesh

from the Android canvas. Text is also missing.

Also see this thread: https://kotlinlang.slack.com/archives/C01D6HTPATV/p1608304979086900

Hi @mzgreen have you succeeded in implementing lottie animations for desktop app?