Hacker News Reader

Comment by CamelRocketFish | Hacker News Reader

Are you on iOS Developer? Anything related to UI is always suggested to be done on the main thread by Apple.

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.

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

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.

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.

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.

How do you animate on the HWUI thread?

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.

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

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.

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”

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

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

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…

The standard path for animation on iOS is that the developer provides new target values (ie the location of something) on the main thread, but the animation and rendering does not block the main thread.

This blog post is about enabling Lottie to use that path.

Core Animation is designed to move work related to playing animations off of the app's main thread. Animations are instead performed by a different process, the OS render server. The UIViews / CALayers / CAAnimations themselves have to be configured on the main thread, but the work to actually play the animation and render each individual frame doesn't happen on the main thread.

It's not isolated to iOS in particular — it's the case in every single GUI framework I've ever dealt with. Android for example would throw an exception if you try touching the views from another thread.

It's a common pattern whenever you don't want the overhead of locks on every single function call. If you're doing anything CPU-intensive, you do it in another thread, synchronize and make API calls in the main thread.

I don't know how deeply animations are tied to the OS API, though.

I’m not, I guess the difference is animation vs UI? From the article, the ios library is set up to run animations off thread on a render server.

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

In fact, it's everything else they encourage you to do off the main thread.

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.

Suggested? It's required, otherwise behavior is undefined for many APIs. And with the main thread checker you now also get runtime issues when you access such APIs.

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.

ComponentKit for Facebook was explicitly built to offload as much ui work as possible to other threads (text sizing being super expensive) and only go back to main to say “here is your new react style model”.

I was very surprised that SwiftUI didn’t do this too.

Right, and only recently did they start providing things like "background-thread image decoding" out of the box. In general you really have to take care that you are marshaling correctly if you bounce between main/background.

macOS not only requires window management on a single thread (common), it requires window management on the actual main thread, i.e., the thread that your program started on. Windows and Linux do not have this limitation. On Windows, you can do window management on any single thread.

Reply on news.ycombinator.com