6 ms·

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

jshier 4y ago
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.
- kridsdale1 4y ago
  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.
yamtaddle 4y ago
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.
twobitshifter 4y ago
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.
- deleted 4y ago
  [deleted]
grishka 4y ago
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.
- TillE 4y ago
  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.
kenferry 4y ago
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.
JamesSwift 4y ago
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.
calstephens98 4y ago
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.
mpweiher 4y ago
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 4y ago
  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...
- incrudible 4y ago
  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 4y ago
    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.
bmitc 4y ago
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.

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.

kridsdale1 4y ago
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.

yamtaddle 4y ago

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.

twobitshifter 4y ago

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.

deleted 4y ago
[deleted]

grishka 4y ago

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.

TillE 4y ago
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.

kenferry 4y ago

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.

JamesSwift 4y ago

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.

calstephens98 4y ago

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.

mpweiher 4y ago

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 4y ago
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...
incrudible 4y ago
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 4y ago
  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.

bmitc 4y ago

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.