Live data from Hacker News

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

medium.com

91–100 of 127 posts

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

#91
post #87
post #83

Earlier quoted context omitted.

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

> you’re drawing too often killing battery.

You say this with zero proof. Checking 100s of widgets to see if they overlap, updating their damage boxes, drawing the parts of the ones that got overlapped, computing clip bounds for each one, switching graphics contexts, to do all that adds up to "killing the battery"

Retained APIs are like using a binary tree where an Immediate mode GUI is like using a vector. CS principles say the tree should be faster as insert and delete are in O(1) but in reality, cache misses and similar things kill all the perf you supposedly gained by over engineering the solution.

The same is often true of retained mode GUIs vs immediate, especially with all the transparency effects in modern UIs. Computing the minimal amount of parts can requires a ton more CPU than just drawing.

As far as caching = retained, no. The difference between an Immediate Mode and a retained mode API is if you, the user, have to create and maintain a tree of retained API widgets. No one is going to implement an immediate mode API and try to have a text widget that word wraps and expect it to have to compute all the word wrapping every frame.

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

#92
post #50

Earlier quoted context omitted.

If you want a course and are willing to pay for it I can recommend School of Motion — https://www.schoolofmotion.com/courses/after-effects-kicksta... (did not take this one, I took more advanced stuff and it was good). Or just like in SE a good way to learn is to choose what you want to make and then watch tutorials on youtube about that specific topic. > I always wanted to use lottie, but never really dived into 2d…

Hijacking thread. Are there any alternatives to AE for those of us that want to animate and export to Lottie but also suffer physical repulsion to Adobe? Is there any serious competition? Lightweight and FOSS are on the wishlist..

Serious competition is the opposite of lightweight and FOSS to be fair.

The most powerful AE competitor(in 2d animation) I've seen is Cavalry. It targets professional motion designers, has neat procedural animation toolset and can export to lottie.

https://cavalry.scenegroup.co/

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

#93
post #32
post #16

Earlier quoted context omitted.

Call me old, but I don’t like it all. This seems over the top

I also think it's over the top and I'm a year or two shy of being a zoomer. Although, I guess being a millennial is considered old by many now. I just wish developers would make mobile UIs consistent with the OS. The Apollo Reddit client and, surprisingly, the official GitHub app are the only third-party apps that I have that feel/look like "native" iOS apps. When it's not over-the-top animations, giant UI elements,…

UI is more than how things look, it’s also about how they work. Both of those apps do bad things in the pursuit of trying to be consistent with OS UI they don’t understand.

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

#95
post #71

Earlier quoted context omitted.

Interesting. Are videogames not beholden to the OS? Are all background processes suspended when SDL is running? Clearly videogames don't have native widgets in the background, nor do they ever "coordinate data downloads" (????) What an absolutely braindead reply. A telltale sign a comment has almost no thought put into it: when you go into the user's post history and see the first page filled with comments written th…

The irony that you’re the one who’s getting worked up about someone else’s internet activity while acting like I’m the one that needs more reality. You’re right your advice is unsolicited, so please kindly keep your issues to yourself. I’d have been happy to discuss the nature of a UIKit and iOS based app cycle that affects these things, but I won’t with such an insufferable person who has nothing better to do than t…

No post body was provided.

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

#96
post #91
post #87

Earlier quoted context omitted.

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

> you’re drawing too often killing battery. You say this with zero proof. Checking 100s of widgets to see if they overlap, updating their damage boxes, drawing the parts of the ones that got overlapped, computing clip bounds for each one, switching graphics contexts, to do all that adds up to "killing the battery" Retained APIs are like using a binary tree where an Immediate mode GUI is like using a vector. CS princi…

Except you’d not be doing all those things that you mentioned. Much like you wouldn’t in a game, you’d be constructing some kind of acceleration structure to only update what’s needed.

With an immediate mode GUI, you have to typically draw most of the hierarchy when even a single widget changes unless you maintain a state based cache. You’re inherently calculating construction of more unless you’re also doing the same optimizations that a retained mode system does.

The tree vs vector analogy isn’t correct either because neither mode prescribe a data structure. I know it was meant to be an analogy but I don’t think it really applies because it doesn’t reflect most code bases and frameworks.

Maybe our definitions of immediate vs retained don’t align.

As for metrics, I don’t have any on hand, and that perhaps makes the discussion moot, but we’ve done multiple UI implementations on my projects, and immediate UIs don’t compare favourably for energy use until and unless you introduce a retained backing.

Indeed that’s what interfaces like Flutter and SwiftUI do by exposing a React+immediate style API while working over a retained base.

I wish I could share our metrics, and I recognize there’s no reason for you to take me at my word on that, but we have done significant work in this area to compare systems for our projects. For reference , we often make use of multiple APIs across our different apps like Dear,Imgui and SwiftUI depending on their needs.

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

#97

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

Maintainer of Lottie for Android here. I left Airbnb 5 years ago and have maintained the library 100% on nights and weekends for the past 6 years. I know your comment was sarcasm but fyi ;)

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

#98
post #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…

Maintainer of Lottie for Android here. The vast majority of work on Lottie has been a passion project on nights and weekends. This particular contribution is actually the rare exception.

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

#99
post #76

Amazing that AirBnb's dev team can release something this smooth and advanced but its messaging system is simply unbearable to use. What's up with that?

Maintainer of Lottie for Android here. Because it’s maintained as a passion project on nights and weekends by a few people. This contribution a rare exception in that it was actually funded and built during work hours at Airbnb. I left Airbnb in 2018 but am still the sole maintainer of the Android library, for example.

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

#100
post #32
post #16

Earlier quoted context omitted.

Call me old, but I don’t like it all. This seems over the top

I also think it's over the top and I'm a year or two shy of being a zoomer. Although, I guess being a millennial is considered old by many now. I just wish developers would make mobile UIs consistent with the OS. The Apollo Reddit client and, surprisingly, the official GitHub app are the only third-party apps that I have that feel/look like "native" iOS apps. When it's not over-the-top animations, giant UI elements,…

Okay Boomer… yeah we’re old now I’m afraid!

Tasteful uses of libraries like this can add a fair bit of “fun” and friendliness to an app, and younger generations do dig them from my user testing at least. Depends on the app and use case I think.

Post reply on HN