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

71–80 of 276 posts

Re: Don't animate height

#71

Post by beejiu »

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…

An engineer could build that much faster than it would take to build an animated GIF in an editor. (For a start, it's a much more complex animation than 6 frames.)

Re: Don't animate height

#72

Post by supermatt »

xp84 wrote: post #60
jakubmazanec wrote: post #35

Earlier quoted context omitted.

GIFs don't scale well (including 2x version is not enough); with CSS (and SVG) you get crisp graphics at any scale. And of course you can use asset SVG files that are cached [1]. [1] https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/E...

Citation needed for 'GIFs don't scale well' (in terms of dimensions. They certainly don't scale well when abused as idiotic versions of videos.) Is this the frontend developer's version of "Postgres doesn't scale. Mongo is Webscale"? Here's a 640x640 GIF. Scales just fine for me, to half-size or to 100px. I'm using a "Retina" screen. https://cdn-icons-gif.flaticon.com/6172/6172533.gif

I’m looking at that on an iPhone, and if I scale (in either direction, pinch or zoom) it I can see a semitransparent halo around it, I would assume from the antialiasing.

So that certainly isn’t scaling well for me.

Re: Don't animate height

#73

Post by dylan604 »

bitpush wrote: post #30
dylan604 wrote: post #28

Earlier quoted context omitted.

Your reply was not necessary though. Every electron app uses more of my computer's resources than when I use the same service through the web browser.

Do you have that documented somewhere, or is it just your observation?

I no longer have the app, but Slack uses <500MB of memory and .2% CPU in a tab in my browser. Back when I had the Slack electron app it was way more than that in use of system resources. I don't know what else to tell you. I don't know what other documentation would be interesting other than my observations made on my own equipment

Re: Don't animate height

#74

Post by beejiu »

xp84 wrote: post #60
jakubmazanec wrote: post #35

Earlier quoted context omitted.

GIFs don't scale well (including 2x version is not enough); with CSS (and SVG) you get crisp graphics at any scale. And of course you can use asset SVG files that are cached [1]. [1] https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/E...

Citation needed for 'GIFs don't scale well' (in terms of dimensions. They certainly don't scale well when abused as idiotic versions of videos.) Is this the frontend developer's version of "Postgres doesn't scale. Mongo is Webscale"? Here's a 640x640 GIF. Scales just fine for me, to half-size or to 100px. I'm using a "Retina" screen. https://cdn-icons-gif.flaticon.com/6172/6172533.gif

GIFs scale quadratically with their resolution and they don't even support an alpha channel, which makes them inflexible.

Re: Don't animate height

#75

Post by Sharlin »

endemic wrote: post #69

ironic that the benefit of using web tech (platform abstractions) can be totally negated by such a small footgun, which then requires insane knowledge of the browser rendering pipeline to solve

One problem is that this is supposedly considered insane esoteric knowledge, when the concept of reflows, and why and when they're triggered, ought to be fairly basic knowledge to every reasonably experienced frontend coder. Up there with "O(n^2) may bite you in the ass". But we've decided that optimizing SEO or conversion rates or whatever is much more important than optimizing rendering.

Re: Don't animate height

#76

Post by liuliu »

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 .

Thank you! This is what I am looking for in HN comments. Layout engine cannot be that stupid per the article. I guess it is not once you give it enough hint.

Re: Don't animate height

#77

Post by hbn »

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.

The heart of the issue isn't that animating height is expensive, it's the downstream effect of that animation repeatedly changing the page's layout and forcing redraws.

Re: Don't animate height

#78

Post by hbn »

dylan604 wrote: post #64
threetonesun wrote: post #29

Earlier quoted context omitted.

Can't imagine anyone is deriving much information value from a visualizer with 3 bars. Apple Music has a similar animation and it will start bouncing when you click play, while the music is clearly downloading and there's no sound.

Just because it isn't useful to the user doesn't mean some dev hasn't spent the cycles doing it. I know I've personally had to write code that was an absolute waste, but some PM wanted and it was coded. Usually so it can be a bullet point in a demo that impresses low skilled PMs or sales drone, but techy user types just roll their eyes when it's pointed out to them.

I think a mic visualizer is very useful to the user. You can tell if you're quiet, clipping, or your mic straight up isn't working at all.

Re: Don't animate height

#79

Post by [deleted] »

hombre_fatal wrote: post #18
HWR_14 wrote: post #9

What amazes me is that so much a M2 Mac's resources would be used to render a website even if it rendered everything from scratch. There is almost no graphic content compared to a video game produced decades ago, and they would easily render a frame in 1/2 the time on decades old hardware

Well, raw graphical content is the easy part. A live layout tree that has to be repainted and composited yet intersect with arbitrary layers like an accessibility tree and what would naively be N:N style calculations is completely different architecture. Consider examples where people toy with the concept of replacing the DOM with a canvas but basic things like text selection don't even work anymore.

[deleted]

Re: Don't animate height

#80

Post by crazygringo »

verall wrote: post #33

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

Seriously. It seems pretty reasonable to allow a web page a total amount of processing that is something like 100% CPU or GPU for 5 seconds. (E.g. can be 25% for 20 seconds.) And beyond that it gets throttled to 3% CPU cumulative max for however long it's been open so far.

And make that the default for popular browsers, so sites are forced to be efficient or else be super super janky and stuttering. And allow a permission for unrestricted processing that things like WebGPU demos or games can ask for.

Post reply on HN