Live data from Hacker News

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

medium.com

81–90 of 127 posts

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

#82

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.

I stay for two weeks now. Some places are just bad. Cash also work.

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

#83
post #59

Earlier quoted context omitted.

This makes me wonder: are immediate-mode GUIs (like Dear ImGui) subject to stuttering and frame-drops under compute-heavy workloads?

Yes they are. They’re beholden to whatever your event loop is. 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 kin…

Do you have any proof of this or just a gut feeling?

Immediate mode guis do cache stuff, at least Dear ImGUI, one of the most popular Immediate mode guis caches. Further, at least in my mobile usage almost everything I do with my phone re-draws the entire screen. The #1 thing to do is scroll through content. There's very few apps I run where only some tiny thing is getting updated. Maybe my music player.

I don't think it's settled that retained more GUIs are a battery win.

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

#84
post #37

Earlier quoted context omitted.

Lottie is an industry standard cross-platform animations pipeline, its not limited to "apps AirBnB is making".

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.

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

#86
post #56

How would these animations compare if they were rendered by a browser rendering engine in CSS and/or SVG?

Animate property of a svg node manually is definitely not a good idea. The overhead is really huge. The browser literally need to redo almost anything from start to render the path and hence the image. And even worse, it also need to synchronize DOM values...etc. Anything you don't care in this use case properly. Let alone the removed node need to be garbage collected, which is also a expensive operation if you even want to do it at 60fps. That is just multi horror movie combined.

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

#87
post #83
post #59

Earlier quoted context omitted.

Yes they are. They’re beholden to whatever your event loop is. 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 kin…

Do you have any proof of this or just a gut feeling? Immediate mode guis do cache stuff, at least Dear ImGUI, one of the most popular Immediate mode guis caches. Further, at least in my mobile usage almost everything I do with my phone re-draws the entire screen. The #1 thing to do is scroll through content. There's very few apps I run where only some tiny thing is getting updated. Maybe my music player. I don't thin…

Once you’ve introduced a state based caching and differentiation layer, you’re introducing retention and are entering into hybrid UI. If you don’t have sufficient caching layers to figure out when something has to update, you’re drawing too often killing battery.

Maybe there are fewer purely immediate mode UI libraries today, which muddies the discussion though.

On the note of the apps used, I would say the vast majority of apps I run only have a few elements updating at any given time. Most of them are based on scrolling for navigation but that’s a small part of what I do. Photo viewing and editing, viewing sites, replying to messages or mail, listening to music. Very little is a full screen update, and if it is, UIKit and SwiftUI are caching large amounts of the view objects to keep things snappy and only doing it when they receive input that requires it. Can immediate GUIs do that too? Of course, but again you enter the domain of retention.

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

#90
I’m fascinated by AirBnB. So much modern tech business orthodoxy is around leveraging your core value proposition and outsourcing everything else. Yet here is AirBnB with their own iOS rendering framework.

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?

Post reply on HN