It’s not reducing the device CPU cost to zero. It’s moving it to a different process that isn’t captured in the profile. Big difference.
Not blocking the main thread is a clear win though. I’m mildly surprised the work isn’t done in an in-process background thread. But I don’t know that type of detail for iOS.
"This system framework renders animations out-of-process with GPU hardware acceleration. Animation playback is managed by a separate system process called the “render server”. "
This was actually a really cool trick that was in-place from day 1 and the main reason iOS animations were smooth on fairly anaemic hardware. And smoother than Android, even when the Android system had beefier hardware and a faster graphics stack.
This blog post is about enabling Lottie to use that path.
>On iOS, the most performant and power-efficient way to play animations is by using Core Animation. *This system framework renders animations out-of-process with GPU hardware acceleration.* Animation playback is managed by a separate system process called the “render server”. This means Core Animation-powered animations don’t contribute to the CPU utilization of the app process itself, and can continue even when its main thread is blocked or busy.
Though I expect things like complex animations are exactly sort of thing that ought to be considered an exception to that guideline. Especially ones that have limited or no interactivity, as in these examples.
It's more shocking to me that Apple hasn't explicitly shifted at least some of its UI frameworks off the main queue in the last 15 years, especially as they've added tools to make it easier. Of course, given the bugs with the parts that are off the main queue, especially in SwiftUI, perhaps that's a good thing.
(But really, moving all these things to CoreAnimation is really nice, kudos to all involved!)
Lottie – Use after effects animations in web and native apps - https://news.ycombinator.com/item?id=29634114 - Dec 2021 (111 comments)
Lottie for Android, iOS, React Native, and Web - https://news.ycombinator.com/item?id=17209832 - June 2018 (18 comments)
Introducing Lottie: Airbnb's tool for adding animations to native apps - https://news.ycombinator.com/item?id=13543927 - Feb 2017 (97 comments)
Others?
Edit: To make it clear: I'm a complete afterfx noob.
> I always wanted to use lottie, but never really dived into 2d animations.
However, as a person who worked as a motion designer for several years, I must say that creating good animations, especially for lotties limited toolset is not a technical problem, but an artistic one. Making animation feel good is hard and takes a lot of practice. Even more for character animation.
Not only did they just release a thing, that does stuff, and is progress. But they did it over the weekend between surf without breaking a sweat because they are pro. /s
Were these issues present only in the iOS version of the library? or are these issues present across android, web, and RN as well? and will these platforms also get the upgrade?
Is it part of their core value prop? Or do they ignore the advice? Or is their success causing them to waste cash on boondoggles like this? Or do these boondoggles help them attract engineering talent for less than they’d otherwise need to pay?
That's sad. That's really, really sad. I get why you would like to work on such a project, but it's got considerable value for AirBnB. Your work doesn't go to the "community", it goes to a large, unscrupulous, unethical money factory.
[0]: https://rive.app/
I guess people in this space are discovering that their old renderers simply aren't as fast as they need them to be, Lottie included.
Thanks, I hate it.
sorry but bullshit! Sure, multi-threaded rendering can give faster results but the apps AirBnB is making could have easily rendered at 60hz with single threaded software rendering in flash in 1998!
I can only guess that too much abstraction throughout the systems has turned into death by 1000 cuts and their solution, instead of getting rid of the 1000 cuts is to apply more band-aids
This isn’t a video game where they’re direct drawing to a graphics context with exclusive use of the resources. They’re also setting up native widgets in the background, coordinating data downloads etc..
Unlike a video game where you control the rendering and scheduling to a greater degree, here they’re beholden to when the OS deems it ready to redraw or scheduling of background processes that may move their task to a lower priority.
Yes you can go fast if you don’t factor in the rest of the system, but they designed Lottie to play well within a retained mode UI setup, which has inherent overhead.
I also think saying that a retained mode UI has inherent overhead is a bit odd. immediate mode UIs have to rebuild their entire draw graph on each frame! meanwhile retained mode UIs have a bunch of metadata letting them get nice optimization improvements. Translating an object means you might not even need to redraw it!
There is definitely a certain truth to the OS being able to just force you down to a lower priority, but I think we all know that iOS is pushing the top app to as high a priority as possible. Meanwhile the "inherent difficulties" with something like AirBnB (getting data over the wire) are definitely inherent but this is why we talk about placeholders and stuff like that yeah?
But if you're in the business of selling rentals it's hard to have so many engineers focused on the performance of the app (especially when you are in the act of being successful already)
What an absolutely braindead reply. A telltale sign a comment has almost no thought put into it: when you go into the user's post history and see the first page filled with comments written that very same day. Scatterbrained to the max.
Hey dude I'm gonna give you some unsolicited advice. Lay off the keyboard for a bit, would ya? Maybe go outside for a walk. You are spending way too much time writing comments on the internet. https://youtu.be/FmDFCKVnaRY?t=341
You shouldn't need multi-threading to render a few thousand objects and most UI apps of the type Lottie is being used for animate 100 or less at a time.
Note: It's good that Lottie runs faster for its users. My point is only that the entire stack is over engineered and the solutions being used are because the stack is bloated and inefficient
That's engineering at scale. It's impossible to remove more than a small fraction of those cuts within any reasonable time frame.
they’re being told when to draw (hence the immediate), so if you suddenly have computation on the same thread that’s blocking OR your thread gets deprioritized , you’ll get stutters.
Immediate mode UIs aren’t very suitable for mobile use though. They don’t have great consideration for battery efficiency, unless you introduce a retained backing of some kind. They’re also not great for accessibility, though that’s mostly just because they’re not native.
