[HN Gopher] Lottie 4.0 for iOS: new render engine with significa...
___________________________________________________________________
Lottie 4.0 for iOS: new render engine with significant performance
improvements
Author : calstephens
Score : 104 points
Date : 2022-12-06 20:37 UTC (2 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| super256 wrote:
| Can anyone recommend a course or tutorial series on creating
| simple 2d bodymovin animations in after effects? I always wanted
| to use lottie, but never really dived into 2d animations.
|
| Edit: To make it clear: I'm a complete afterfx noob.
| another_kel wrote:
| 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
| animations.
|
| However, as a person who worked as a motion designer for
| several years, I must say that creating good animations,
| especially for lotties limited toolset is not a technical
| problem, but an artistic one. Making animation feel good is
| hard and takes a lot of practice. Even more for character
| animation.
| skilled wrote:
| I suppose Rive [0] will have to make a response to this to
| clarify just how much better it is than Lottie - as far as
| performance goes.
|
| [0]: https://rive.app/
| satvikpendem wrote:
| Rive has a new renderer as well coming out:
| https://twitter.com/guidorosso/status/1595187838454140928
|
| I guess people in this space are discovering that their old
| renderers simply aren't as fast as they need them to be, Lottie
| included.
| jagged-chisel wrote:
| Does Rive run After Effects animations? I thought that was
| Lottie's purpose in life, to bring AE to all the things.
| Fauntleroy wrote:
| Rive does not. They're positioning themselves as an
| alternative with their own state machine / visual editor
| pipeline
| projektfu wrote:
| https://rive.app/use-cases
|
| Thanks, I hate it.
| ugh123 wrote:
| Insightful /s
| [deleted]
| satvikpendem wrote:
| I like it. Obviously don't use it for everything but small UX
| touches here and there make a brand more likeable to users,
| in my experience doing frontend and design interviews.
| jw1224 wrote:
| Really, why? I thought they were charming and well-executed.
| foolfoolz wrote:
| things like this violate the design principles values by
| novice and power users. novice users that use something
| once a week or month may enjoy additional visual cues and
| animations to be friendly and welcoming. low information
| density to not overwhelm.
|
| power users that use something every day or many times a
| day prefer things that are static, fast, and higher
| information density.
|
| this is from designing the user interface, 1995
| jw1224 wrote:
| Agreed, I wouldn't want to see one of these every time I
| refresh my inbox. But this is a demo page, showing the
| capabilities of the animation library?
| projektfu wrote:
| Some people really like ketchup on pizza. I don't. It's a
| matter of individual taste.
| jw1224 wrote:
| Sure, but, it's an animation library? Kinda like saying
| you don't like "photography".
| projektfu wrote:
| I don't like the suggestions in the use cases. Like if
| you didn't know about cameras and asked, why? And someone
| showed you all the grotesque images they can capture, as
| what they think is a beautiful demo. As a bonus, their
| camera makes them more grotesque with less effort.
| yreg wrote:
| prefers-reduced-motion is there for you (and anyone using
| these charming animations should obey the setting)
| projektfu wrote:
| Thanks, already use it.
| zahrc wrote:
| Call me old, but I don't like it all. This seems over the top
| namuol wrote:
| Hello, fellow old! I don't like it, but only because it's
| hard to employ tastefully. That doesn't mean it's all bad,
| though.
| nvrspyx wrote:
| 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,
| tutorial modals, or fullscreen pop-ups, it's small details
| like the (IMO ugly) custom font and the sharp-cornered
| buttons in the Dropbox app. At least for that particular
| app, I can just use the built-in Files app, but no such
| luck for other apps.
| Dig1t wrote:
| This is awesome, I really hope they add better support for
| SwiftUI. It is annoying having to wrap this stuff in
| UIViewRepresentable.
| havo wrote:
| Great work on the new release! I've been using Lottie for a while
| now and have definitely noticed the performance improvements with
| the new rendering engine. It's really exciting to see Lottie
| continue to evolve and improve. Keep up the good work!
| calstephens98 wrote:
| Thanks!
| [deleted]
| gfxgirl wrote:
| > These issues are inherent limitations of using a main-thread-
| bound rendering architecture.
|
| sorry but bullshit! Sure, multi-threaded rendering can give
| faster results but the apps AirBnB is making could have easily
| rendered at 60hz with single threaded software rendering in flash
| in 1998!
|
| I can only guess that too much abstraction throughout the systems
| has turned into death by 1000 cuts and their solution, instead of
| getting rid of the 1000 cuts is to apply more band-aids
| JamesSwift wrote:
| Lottie is an industry standard cross-platform animations
| pipeline, its not limited to "apps AirBnB is making".
| gfxgirl wrote:
| 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
| inefficient
| dang wrote:
| Related:
|
| _Lottie 4.0 for iOS: new render engine with significant
| performance improvements_ -
| https://news.ycombinator.com/item?id=33886673 - Dec 2022 (12
| comments)
|
| _Lottie - Use after effects animations in web and native apps_ -
| https://news.ycombinator.com/item?id=29634114 - Dec 2021 (111
| comments)
|
| _Lottie for Android, iOS, React Native, and Web_ -
| https://news.ycombinator.com/item?id=17209832 - June 2018 (18
| comments)
|
| _Introducing Lottie: Airbnb 's tool for adding animations to
| native apps_ - https://news.ycombinator.com/item?id=13543927 -
| Feb 2017 (97 comments)
|
| Others?
| twobitshifter wrote:
| Crazy to me that animations would have been done on the main
| thread but that showed how far you can get with kiss. The
| performance improvement they're showing is great -17% CPU to
| display a loading animation down to 0. Before the animation could
| be interfering with the loading!
| phdelightful wrote:
| TFA says that their app loads faster for this reason with the
| new implementation.
| CamelRocketFish wrote:
| Are you on iOS Developer? Anything related to UI is always
| suggested to be done on the main thread by Apple.
| JamesSwift wrote:
| 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.
| twobitshifter wrote:
| 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.
| mpweiher wrote:
| 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.
| grishka wrote:
| 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.
| jshier wrote:
| 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.
| yamtaddle wrote:
| 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.
| calstephens98 wrote:
| 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.
| kenferry wrote:
| 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.
| amelius wrote:
| What is that header image of a beach about? Is that a rendering?
| tomxor wrote:
| That's there to ensure you know how cool and hip they are.
|
| Not only did they just release a thing, that does stuff, and is
| progress. But they did it over the weekend between surf without
| breaking a sweat because they are pro. /s
___________________________________________________________________
(page generated 2022-12-06 23:00 UTC)