Hacker News Reader

Comment by robocat | Hacker News Reader

Example: "Our app was mysteriously using 60% CPU and 25% GPU. It turned out this was due to a tiny CSS animation [of an equaliser icon]"

https://www.granola.ai/blog/dont-animate-height

View on HN

I remember Slack eating up my CPU when it had to display several animanted emojis at once. Use some 20+ emojis and the intel mb pro couldn't handle it. Luckily they knew and there was an option to disable the animation. Now I have no idea if they fixed it since or it is one of those things that was "fixed" by M1.

Would like to see a write up on how it's even possible to achieve that when PCs from 20-30 years ago had no issue with such task.

> Would like to see a write up on how it's even possible to achieve that when PCs from 20-30 years ago had no issue with such task.

Electron.

But that's just a browser, right? I'm pretty sure my browser in 2005 could display dozens of gifs. There must have been a series of decisions by devs to do it in some super convoluted way. I can see each emoji being an iframe with a full react app doing the animation. But even that should be fine? Maybe?

It's "just a browser" in the same sense that the Linux kernel and GNU are "just an operating system".

It's one of the most complex pieces of software - perhaps even human designed systems - ever to exist and we're using it to render a few polygons and drop shadows because the C++ committee made a bunch of mistakes decades ago so now our webdevs are mortally afraid of CMake and Qt/QML. Or GTK. Or whatever. Pretty much the only people that seem to put out native GUI tools in any significant quantity are Apple developers.

The tradeoffs that Blink and V8 engineers have made to support the entirety of the internet and the morass of web development precludes efficient use of resources for simpler purposes, like rendering an animation. After all, there a billion React hooks and ad tracking scripts to optimize, otherwise bounce rates will increase.

> precludes efficient use of resources for simpler purposes

Strong disagree. If it were an animated gif then the browser will be astonishingly efficient because of crazy good optimisations.

The underlying reason is that developers are limited to the techniques/toolbox they know. The performance costs are unpredictable because of:

(1) the declarative style (using imperative solutions would have other costs),

(2) debugging browser performance regressions is difficult (SQL EXPLAIN is more learnable).

Browsers enable developers. I could design that animation in CSS even though I'm a developer, plus I understand the article fully. I couldn't design an animated gif because I am totally unfamiliar with any tools for achieving that.

I think the Blink and V8 teams do an exceptionally good job when choosing compromises. HTML/CSS/SVG/JS and Chromium are winning the UI wars because they deliver practical and efficient enough solutions. Other UI solutions I have experienced all have other downsides. Browsers are magical.

I mostly really agree with your comment.

Animated gifs are probably not an issue anymore. In the case of the equalizer icon, the OP used CSS animations that made the browser work in a very non-optimal way. Same thing probably applies to the animated emojis.

Part of the problem is that because it's "just a browser", devs have to come up with browser-friendly ways to implement some functionality that would be very simple if it were a native app. Sometimes resulting in bugs like https://github.com/microsoft/vscode/issues/22900 ("VS Code uses 13% CPU when focused and idle, draining battery ... due to the blinking cursor rendering").

Note that this isn't even a case of whoever implemented that cursor "doing it wrong"; to quote another comment on that bug from a Chrome dev:

> Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. In this case, VSCode is probably using the most reasonable approach to blinking a cursor: a step timing-function with a CSS keyframe animation. This tells the browser to only change the opacity every 500ms. Meanwhile, Chrome hasn't yet optimised this completely yet, hence http://crbug.com/361587. So currently, Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval. I'm confident that the engineers working on Chrome's style components can sort this out, but it'll take a little bit of work.

While that's part of it, it's also that there's simply little focus on performance; developers trust the system they build on top of, and animations are a solved problem in terms of performance, right?

Animations on a HTML controled by a css are a solved problem.

It is a bad idea.

> I remember Slack eating up my CPU when it had to display several animanted emojis at once.

I remember using phpBB back in the late 2000's, viewing a page that had at least 100 animated emoticons on it.

It would slow IE6 down to a halt. But then I tried Chrome or Firefox (I forget which one) and it didn't even blink showing the same page. I even remember reading some developer posts about things like that at the time.

> Would like to see a write up on how it's even possible to achieve that when PCs from 20-30 years ago had no issue with such task.

At a guess, by something in the UI framework turning an O(n) task into an O(n^2) task. Seen that happen in person, the iPhone app was taking 20 minutes(!) to start up in some conditions, the developer responsible insisted the code couldn't possibly be improved, the next day I'd found the un-necessary O(n^2) op and reduced that to a few hundred milliseconds.

The over-abstraction of current programming is, I think, a mistake — I can see why the approach in React and SwiftUI is tempting, why people want to write code that way, but I think it puts too much into magic black-boxes. If you change your thinking just a bit, the older ways of writing UI are not that difficult, and much more performant.

I have a bunch of other related opinions about e.g. why VIPER is slightly worse than an entire pantheon of god classes combined with a thousand lines inside an if-block: https://benwheatley.github.io/blog/2024/04/07-21.31.19.html

Or more recently, NPM's infamous "Progress bar noticeably slows down npm install #11283" issue

[1]: https://github.com/npm/npm/issues/11283

A thing I discovered by myself when I was a teenager: do not update progress bars on every loop.

There's a lot of things front-end developers (be they web or graphical terminal) can learn from the game development world. I can recommend playing with e.g. Pico 8 sometime, it's artificially constrained so you have to work with the limitations instead of do the usual relatively naive work. It's LUA coding so it shouldn't be a problem for JS developers, assuming they don't mind working in a 20 column code editor (or thereabouts).

Games developers are not magically safe from the progress bar mistake.

I think it’s more so important to get familiar with loop/event based programming. Most of my experience is in the request/response mindset of web requests so when I try out game dev, arduino dev, C# desktop apps, etc I find my mental model has to shift drastically

Loops occur so fast it’s pretty standard to have to put some throttling logic in the code which I’ve never had to do in web dev except perhaps the document.ready statement in JavaScript to make sure the dom has been loaded.

Same here. I often implemented like this, where n was some reasonable value:

    if iteration % n === 0:
        update_progress()

I normally do it with a bitwise and of numbers that end with a sequence of 1s, like 7. so `i & 7 == 7`

Why was the solution to optimize the animation instead of... using a static asset?

We paid for the whole CSS spec and we're gonna use the whole CSS spec.

This, but for everything wevdev-related in the past ten years.

Because it provides an indication that the app is receiving your voice input?

I think they're suggesting an animated PNG or GIF.

Or even better an animated SVG. Put it inside an <img> tag with a known width and height.

I'd be very surprised if SVG animations don't use substantially the same rendering paths that CSS animations do. In fact, if anything, I'd expect CSS animations to receive more time and attention from browser devs than the old SMIL elements and attributes, to whatever extent that they aren't equivalent internally.

SVGs are usually animated with CSS.

Yeah but the crux of the problem is when height is animated the browser needs to redo the layout. Here the animation is contained entirely within an <img> tag with known width and height.

That's something I'd use a canvas or even a SVG for. SVG FFT Analyzer sound like a fun project.

Oh, looks like I'm way late: https://cprimozic.net/blog/building-a-signal-analyzer-with-m...

How would an animated PNG or GIF respond when the user is speaking?

Switch between different PNGs depending on voice activity.

that's how veadotube works for vtubers.

I assume there's a way to pause a gif.

That would be more optimized for sure. But it wouldn't be scalable and would take more work to create than what looks like a pretty simple change.

This reminds me of having to go into spotify's package files to track down their version of this animation (an animated svg of a bar chart) and kill it, because it would destroy performance on my PC so badly that it was affecting other programs, causing hitches and freezes.

The animation's still there — and my PC is better now, so it doesn't stutter — but I'm willing to bet it's still burning waaay too many watts, for something so trivial.

This is why it pays out to turn on "Paint Flashing" [1] in the web console, even if just from time to time.

1: https://web.dev/articles/simplify-paint-complexity-and-reduc...

Me, who already renders a canvas on the whole page so it highlights the whole thing constantly: "Hmm yes the painting here is made out of painting."

That's cool, I don't know how popular canvas heavy apps are these days, what kind of apps are you working with?

I used to work on a set top box app, and for some of the features, replacing the whole page with a single canvas was the only way to get steady FPS.

CSS animations make Flash look efficient by comparison.

Reply on news.ycombinator.com