Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lottie 4.0 for iOS: new render engine with significant performance improvements

medium.com

Post reply on HN
Print view View original

111–120 of 127 posts

Re: Lottie 4.0 for iOS: new render engine with significant performance improvements

#111

Post by mike_hearn »

plorkyeran wrote: post #84
gfxgirl wrote: post #37

Earlier quoted context omitted.

Irrelevant, the apps it's being used for would run fine on a 25yr old machine at 60fps. 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…

I agree with the general point you're making, but a 1997 computer would not be able to render even just a basic loading spinner at 1170x2532 at 60 FPS. Software rendering would be impossible even with an infinitely fast CPU as it would exceed the bandwidth limit of AGP 1.0, which itself only came out that year. The graphics hardware at the time simply did not support that resolution at any speed.

This is a common problem when people complain about graphics performance and compare to older hardware - we forget how much higher modern screen resolutions are. It's not a smoothly scaling problem either. As often with scaling, you hit problems at particular levels that require a totally new solution to the problem. CPU speeds stagnated whilst screen technologies didn't, hence, complexity.

Re: Lottie 4.0 for iOS: new render engine with significant performance improvements

#112

Post by ricardobeat »

bobbylarrybobby wrote: post #77
mpweiher wrote: post #30

Earlier quoted context omitted.

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 smoothe…

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”

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

Re: Lottie 4.0 for iOS: new render engine with significant performance improvements

#113

Post by ricardobeat »

vvanders wrote: post #74
halpmeh wrote: post #70

Earlier quoted context omitted.

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.

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.

Re: Lottie 4.0 for iOS: new render engine with significant performance improvements

#115

Post by meindnoch »

bobbylarrybobby wrote: post #77
mpweiher wrote: post #30

Earlier quoted context omitted.

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 smoothe…

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”

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…

Re: Lottie 4.0 for iOS: new render engine with significant performance improvements

#116

Post by tgv »

blowski wrote: post #107
tgv wrote: post #103

Earlier quoted context omitted.

> The vast majority of work on Lottie has been a passion project on nights and weekends. 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.

1. It’s open sourced, so it goes to both. Either AirBnB sponsor the build and promote it, or the community builds it and AirBnB uses it. I’m not sure why the latter would be better than the former. It’s better for the world than companies keeping all their libraries closed source. 2. AirBnB’s backing probably gives it more reach because it’s more likely to be maintained. 3. It’s up to the OP where they spend their ti…

1. This is not a common library that fits everywhere. It's pretty specialized. Using its full potential almost requires a commercial environment, because of the design and graphics needed. For everyone else, normal animations are annoying enough.

3. The parent post said: passion project/nights+weekends. That doesn't sound like multiple way compensation.

It's not about negative behavior of big tech, but more of a "grind" mentality gone astray. I can totally understand being (somewhat) proud of a project like this: it looks friggin' good. I also expect a company to grab whatever it can; it's the way of the world, and some companies are quite immoral. But we should not be working on something of considerable value to entities with deep pockets for free, just because it hits those 2010s linked-in bingo words. That's not where your self-worth as engineers should come from.

Re: Lottie 4.0 for iOS: new render engine with significant performance improvements

#117

Post by bowsamic »

cactusplant7374 wrote: post #81
exabrial wrote: post #60

Well now I understand why airbnb fees are so ridiculous... Guess all that UI fanciness comes at a price.

I stay in the Airbnb for a month. If I like it I pay direct with bank transfers.

That is terrible

Re: Lottie 4.0 for iOS: new render engine with significant performance improvements

#118

Post by calo_star »

saagarjha wrote: post #94
calo_star wrote: post #89

How do you animate paths (morphing shapes) with Core Animation?

CAShapeLayer has support for this.

Fascinating! I touched AppKit and Core Animation a long time ago and I had no idea this existed. Does this mean the gesture animations in iOS system (such as opening an app on springboard) are drawn by this?

Re: Lottie 4.0 for iOS: new render engine with significant performance improvements

#119

Post by [deleted] »

incrudible wrote: post #110
halpmeh wrote: post #70

Earlier quoted context omitted.

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.

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.

[deleted]

Re: Lottie 4.0 for iOS: new render engine with significant performance improvements

#120

Post by incrudible »

ricardobeat wrote: post #113
vvanders wrote: post #74

Earlier quoted context omitted.

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.

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.

Post reply on HN