Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't animate height

granola.ai

Post reply on HN
Print view View original

141–150 of 276 posts

Re: Don't animate height

#141

Post by Saris »

deathanatos wrote: post #139
Saris wrote: post #116

Why are the bars on a little button animated in the first place? I don't get it.

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.

Re: Don't animate height

#142

Post by notatoad »

alexchantavy wrote: post #108
deepsun wrote: post #50

Just 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?

not really. the web is 30+ years of fixes, shortcuts, compatibility hacks, tech industry politics, and other assorted mistakes.

the "first principles" to understand it all is the complete set of mailing list archives of the WhatWG, plus the archives of the bug trackers of all the major browsers.

Re: Don't animate height

#143

Post by MITSardine »

xp84 wrote: post #56
MITSardine wrote: post #44

Earlier quoted context omitted.

The app taking "only" 6% of a $3k laptop's CPU to show two lines of text and a little 2D animation also gave me pause, but maybe this is just how it is. Still I wonder how people were squeezing pacman out of prehistoric machines, and we're using an 80's supercomputer worth of CPU power (not that far given they were in the ~ 1 GFLOP range) to animate three green bars today.

They actually knew how to code back then. I fancy myself someone who cares about performance and take a great effort to not do wasteful stupidity like those CSS animations for a decorative element, but compared to 80s programmers, I'm actually a complete fraud, because I do everything in interpreted languages that do 10,000 things behind the scenes for every line of code I write. I could never make an Atari computer…

Necessity is the mother of invention!

Another way to look at it, is only those who could write very optimized code could get anything meaningful running on those machines. Hence all (?) software from far enough back was optimized down to death.

I'm personally grateful I've never had to wrangle hardware bugs into features and other such hacks one stumbles upon in anecdotes from those eras... even though there is a certain charm to it all.

Re: Don't animate height

#144

Post by efilife »

utopman wrote: post #104
MITSardine wrote: post #52

Earlier quoted context omitted.

So, the CRAY-2 built in 1985 was rated at 1.9 GFLOPS. The M2 the author uses seems to be benchmarked at around 6GFLOPs per core [1]. So this 6% of the author's CPU (assuming charitably this is a single core) corresponds to about 20% of the mid 80's peak supercomputer capacity. People were already using those computers for applications that go slightly beyond animating 5 x 3 green little bars up and down at the time..…

This. I did not find other comments like this in this thread. 6% M2 cpu (even single core) is a huge computing budget for such a small feature. At this point I don't really understand why OP seems happy with this result (sorry). I think even a naive canvas implementation can really and quite easily cut most of this computing budget. Also, a pure css animated thing should use mostly gpu in a right DOM implementation.…

I did find a comment like this. It's dead

https://news.ycombinator.com/item?id=44653068

Re: Don't animate height

#145

Post by efilife »

deathanatos wrote: post #140
xp84 wrote: post #31

Here's the part that makes me confused/angry: this is a flat style icon with maybe 4 or 8 colors displayed on a static flat green background. 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. With CSS you can easily make that GIF a background image and position it correctly in the or whatev…

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

Hey, grammar police here. The animation is supposeD, like in "watcheD" not "watche".

Its meter, not "it's". Its means possession, it's is a contraction that means "it is"

Re: Don't animate height

#146

Post by Levitating »

Does a note taking app need such an animation if apparently it's that easy to accidentally drain the users battery?

The UI of this app literally only has a piece of text, a button and this animated indicator. To render this it needs an entire chromium browser loaded into memory, and still it has performance issues.

I will always prefer software written in native graphics toolkits. I understand the benefits of using electron but the only electron based software I've ever liked was vscode.

Re: Don't animate height

#147

Post by makeitdouble »

Varelion wrote: post #42

It seems beyond absurd to me, that this tiny animation should be costing as much as 6% of CPU. There has to be more optimal ways to do this.

I assume 6% is for the whole page.

That's still a lot for a single page IMHO, but it seems that service is doing resource expensive things in the first place.

Re: Don't animate height

#149

Post by Eric_WVGG »

moritzwarhier wrote: post #37
Eric_WVGG wrote: post #21

My head is sort of reeling from this. If height animations are that expensive today, imagine how expensive (and still commonplace) they were twenty years ago. I fortunately quit animating height quite a long time ago in favor of similar transform techniques, but… wow, still crazy to learn the magnitude of this common operation.

It's really simple. Don't animate layout, especially if your DOM is huge. If your element floats absolutely positioned outside the layout flow, animating height would not be a problem. And if the browser facilities for animating height/max-height, especially to/from auto, get better, it surely will become more common. Right now, I wouldn't call it common. It's a common requirement, but only until you start to conside…

You can animate an absolute positioned div without it obviously altering what a normal person would call "the layout." That's not simple unless one is willing to dig very deeply into the how web browser rendering works. And really still not simple. Otherwise this article wouldn't have been written.

Re: Don't animate height

#150

Post by Eric_WVGG »

cvoss wrote: post #90
Eric_WVGG wrote: post #21

My head is sort of reeling from this. If height animations are that expensive today, imagine how expensive (and still commonplace) they were twenty years ago. I fortunately quit animating height quite a long time ago in favor of similar transform techniques, but… wow, still crazy to learn the magnitude of this common operation.

But it wasn't expensive twenty years ago. Twenty years ago people actually knew how to efficiently use their limited computational resources.

so it wasn't expensive because people didn't do it? They did.
Post reply on HN