> On my M2 MacBook, the renderer process is now using 6% CPU (down from 15%), and the GPU process is now using 6% CPU and less than 1% GPU (down from 25% and 20%)
Ouch. All of this for a tiny visualizer animation.
Don't animate height
201–210 of 276 posts
Re: Don't animate height
#202Cool article!
> On my M2 MacBook, the renderer process is now using 6% CPU (down from 15%), and the GPU process is now using 6% CPU and less than 1% GPU (down from 25% and 20%).
This still feels way too much compute for a tiny animation updating a couple times a second.
Re: Don't animate height
#203Just wrap it in a container with fixed height and "overflow: hidden". Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster. By the way, the same trick was speeding up large rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of .
Is there a good way to learn techniques like this from first principles other than trying to become an employed frontend dev?
[deleted]
Re: Don't animate height
#204Is it possible to restrict this as a user? Like to force webpages to use under a certain amount of render/paint time/resources or else just break so that one dumb tab doesn't use up all my battery? Then I can opt-in to greater resources usage if it's a webpage I actually care about. I've seen the "This webpage is using alot of resources" popup before but I don't think it would happen in this case. Because honestly I…
Your browser should allow you to override all CSS on the web. Here's how I disable CSS animations in Firefox: https://news.ycombinator.com/item?id=33223080
This is a level too deep. I don’t want to dictate what a website can and can’t do to limit resource usage; I just want to limit resource usage.
Sure, noodling with content blockers has its own advantages, but for this particular case they cut at the wrong abstraction matter.
Re: Don't animate height
#205The fact that this little animation can have such heavy performance impact tells us one thing: CSS design is flawed. That‘s it. That‘s the whole story.
It really isn't.
How can the browser know if an arbitrary animation can change an element's height? I'll bet 10 bucks this is equivalent to halting problem.
Unless you 1) don't support full SVG spec or 2) separate SVG elements from the layout completely, it's not a problem that is solvable by browser. The developers need to wrap their animation in a fixed size element and it's very reasonable to expect them to do so.
Plus, the CSS spec doesn't prevent browser vendors from optimizing this specific use case if it's really that needed.
(Of course in the case of this simple web app in OP, the correct solution is to not use animation at all.)
Re: Don't animate height
#206Earlier quoted context omitted.
> A nice starting place would be if one of the major browsers added an easy to use extension point for swapping out languages. (at least I'm not aware of this existing, nor that I've looked) What would that actually mean in practice that would be different from how Dartium did it?
Well I don't know how dartium did it really, but it seems to me like "add a new website implementation language to Chromium" would be a tutorial on Chrome/Chromium's home page. Such that one could throw together, I dunno, news.ycombinator.com/index.z and see if they can do a better job than HTML/CSS. As far as the actual solution to try for, table stakes is a native implementation of something that looks like React (…
> Such that one could throw together, I dunno, news.ycombinator.com/index.z and see if they can do a better job than HTML/CSS.
What would be the use of that? It would help people who want to make prototypes of a different web with no hope of it ever getting adopted, but that's not a huge market.
> table stakes is a native implementation of something that looks like React (but presumably reimagined from scratch)
Like a component layer? Browsers have tried with e.g. XUL or WebComponents, how would you avoid the problems of those?
Re: Don't animate height
#207Earlier quoted context omitted.
> I could have built this 25 years ago with a single GIF with about 6 frames, that was a couple of kilobytes and would be performant on the (relative) potato computers we had then. […] But modern "web designers" feel the need to spend how long carefully crafting that CSS animation which adds dozens of lines of code to the codebase and burns a ton of CPU...why? Just because you can, I assume? The animation (which is n…
I can't use the app in question, but I haven't seen any proof it doesn't just "dance when receiving audio". If it tracks amplitude and pitch, I'd still say it's overengineered, since in practice no one can discern anything useful except 2 or maybe 3 states (silent, quiet, not quiet).
True, the article didn't say that it for sure isn't being used as a glorified GIF, but … why not just give the benefit of the doubt that it UI element is doing the thing the UI element ought to do? Then, "Here's how that turned into a performance problem" followed by the rest of the article.
> I'd still say it's overengineered, since in practice no one can discern anything useful except 2 or maybe 3 states (silent, quiet, not quiet).
For most use cases … that's all that's necessary? It helps confirm that the audio equipment and various software layers are working.
… like I use these UI elements all the time, because Bluetooth has decided that "nah, I'm not going to connect, even though every device reports as connected".
Re: Don't animate height
#208Earlier quoted context omitted.
This looks like a very typical audio recording UI element. The bars are animated to the volume of the recorded audio. Helps the user see that the application is picking up their mic. It's a digital analog of a VU meter on a mixing console, though the UI has morphed over time. (Like that the lines vertically centered, vs. being on aligned bottom like you might see on a real-world meter.)
Except that it's not an actual meter, it's just a fake animation.
… we don't know this, and I'm willing to extend the article the benefit of the doubt, because it isn't relevant to the core of the article.
Re: Don't animate height
#209Earlier quoted context omitted.
This looks like a very typical audio recording UI element. The bars are animated to the volume of the recorded audio. Helps the user see that the application is picking up their mic. It's a digital analog of a VU meter on a mixing console, though the UI has morphed over time. (Like that the lines vertically centered, vs. being on aligned bottom like you might see on a real-world meter.)
Man at that point why not make it bigger and put a proper dB scale on it, at least it would be useful then.
… because it doesn't need to be bigger…? The purpose is to convey that "hey, the audio equipment is working". I use these all day to debug things like "am I not recording, or is the other side's volume muted?" We need "videoconferencing" or "notetaking" app levels of accuracy; it's not a sound studio app?
Not to mention how much dB as a unit freaks people out.