5 ms·

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

by rplnt 2y ago

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.

throwup238 2y ago
> 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.
- rplnt 2y ago
  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?
  - throwup238 2y ago
    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.
    - robocat 2y ago
      > 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.
  - schwartzworld 2y ago
    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.
  - int_19h 2y ago
    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 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 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.
- Cthulhu_ 2y ago
  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?
  - lomase 2y ago
    Animations on a HTML controled by a css are a solved problem. It is a bad idea.
bluedino 2y ago
> 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.
ben_w 2y ago
> 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 https://benwheatley.github.io/blog/2024/04/07-21.31.19.html

by rplnt 2y ago

throwup238 2y ago

> 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.

rplnt 2y ago
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?
- throwup238 2y ago
  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.
  - robocat 2y ago
    > 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.
- schwartzworld 2y ago
  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.
- int_19h 2y ago
  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 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 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.
Cthulhu_ 2y ago
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?
- lomase 2y ago
  Animations on a HTML controled by a css are a solved problem. It is a bad idea.

bluedino 2y ago

> 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.

ben_w 2y ago

> 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 https://benwheatley.github.io/blog/2024/04/07-21.31.19.html