[mpweiher]

No. Animations are usually performed by the GPU under the control of a separate process.

"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.

[noduerme]

It was also available since at least 2014 when animating with AIR (yes, Flash AS3), along w/ fine-grained control over what was uploaded to the GPU and when, through an API that deployed seamlessly to iOS and Android. There's no reason the nascent Flash mobile plugin wouldn't have supported this too, if it had gotten much past beta, since GPU leveraging was available from Flash in desktop browsers earlier than that.

Keeping the GPU context when switching mobile apps was always a challenge, though, and often the animation state would need to be rebuilt if the context was dropped. I'd assume that's still an issue something like Lottie needs to handle, whether it does so under the hood or not...

[bobbylarrybobby]

On iOS, you schedule animations (and all UI updates, period) on the main thread. iOS is then free to make those happen in a non blocking way. iOS dev 101 is “don't do long synchronous work on the main thread because your app will lose the ability to update its UI for the duration”

[meindnoch]

Lottie was running the animations on the main thread, via CADisplayLink.

By the way, you can “schedule” animations from any thread if you use CoreAnimation directly. CALayers are thread-safe. You just need to manage the CATransaction yourself.

Also, trying to explain “iOS 101” to Marcel Weiher is a bit rich…

[ricardobeat]

Scheduling an animation from the main thread is very different from running the animation on the main thread:

> Once per frame, Lottie would execute code on the main thread to advance the progress of the animation and re-render its content

[vijaybritto]

It's common for all client apps to not block the main thread be it iOS, Android or Web

[incrudible]

GPUs have no concept of animation. A frame rendered by a GPU has a fixed state, usually computed on the CPU. Until recently, this was usually done on the main thread, because graphics APIs had poor support for being used from multiple threads. I have no idea what AirBNB was doing to fail 60Hz on rather simple scenes with a single thread, but you can rest assured that it is possible without multiple threads or even processes.

[halpmeh]

The point is that iOS has always used a separate process for computing the GPU state. Android does this on the main thread, which is why Android feels like garbage. And I say this as a former Android developer. Animations on Android feel like peanut butter. They always will until they are moved off the main thread.

[incrudible]

No, it has not. If you talked to the GPU through OpenGL, you did it on the main thread. You pass all the state that you computed in that thread. Chances are you computed that state in that thread too.

There are some optimizations regarding e.g. scrolling being computed in a different thread/process (still on the CPU) before compositing (on the GPU) but that is not a requirement for smooth animation.

[vvanders]

That's not technically correct(which is always the best kind of correct :) ), HWUI has been multithreaded for quite a long while now. That doesn't prevent apps from doing bad things but it's been possible to do smooth animation on Android since the days of project butter.

[ricardobeat]

My low-end Android device disagrees. Eight cores @ 2.3ghz and _everything_ stutters, on a barebones OS with nothing installed.

Pixel phones fare a lot better, but I suspect it's just a result of their sheer processing power.

[incrudible]

> barebones OS

Android is the opposite of barebones. It comes loaded with crap, much of it is using "stop the world" garbage collection while also producing lots of garbage. Building on Java is Android's original sin. You could still build an NDK app, talk to OpenGL, and hit 60Hz on low-end devices, years ago, but that's not how most stuff is developed. There are layers upon layers of crap between applications and the hardware, to the point where apparently people have come to believe that you need special OS interfaces to do smooth animation.

[halpmeh]

How do you animate on the HWUI thread?