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

11–20 of 276 posts

Re: Don't animate height

#11

Post by alterom »

So, after all the optimization, they're using 6% of the CPU to display what amounts to a tiny animated GIF that 1990s PCs would have no problem with.

But it's vector graphics!, you might say. Yeah, like Flash, which ran fine on Pentium II, with plenty CPU cycles to spare.

Pardon me, and I don't say it lightly, but... WTF?!

Re: Don't animate height

#12

Post by bob1029 »

I would also suggest looking into the following in this case:

https://developer.mozilla.org/en-US/docs/Web/CSS/contain

https://developer.mozilla.org/en-US/docs/Web/CSS/will-change

There are hints you can provide to the browser that may have an impact in scenarios where you are animating layout properties.

Re: Don't animate height

#13

Post by dylan604 »

"What is Granola spending those cycles on? It's an Electron app"

Yup. Matches my experience with pretty much every Electron app. Great that the dev tracked it down, but every Electron app is a waste of...electrons

Re: Don't animate height

#14

Post by nightpool »

jtangelder wrote: post #3

Wondering what the performance of a simple animated gif would be, instead of the composite layer transformations.

GIFs historically were pretty unoptimized from a display perspective (as anyone with a moderately-active Tumblr dashboard could tell you), so I wouldn't be surprised if it was worse.

Re: Don't animate height

#15

Post by bijection »

bob1029 wrote: post #12

I would also suggest looking into the following in this case: https://developer.mozilla.org/en-US/docs/Web/CSS/contain https://developer.mozilla.org/en-US/docs/Web/CSS/will-change There are hints you can provide to the browser that may have an impact in scenarios where you are animating layout properties.

I was just starting a comment on this but you beat me to it! I believe

  contain: strict;
on the parent element would have been sufficient here.

Re: Don't animate height

#17

Post by dylan604 »

jtangelder wrote: post #3

Wondering what the performance of a simple animated gif would be, instead of the composite layer transformations.

If the bars are not related to actual data and are purely just pre-canned animation, the gif would just come with additional file size for a one time cached type of download. If the bars do need to be animated to real-time data coming in, then the gif would not be the right fit for that need.

Re: Don't animate height

#18

Post by hombre_fatal »

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.

Re: Don't animate height

#20

Post by Eric_WVGG »

h1fra wrote: post #8

dumb question: would putting the parent div in absolute positioning solve the compositing?

It already was. The whole point of this is that any height change is part of an expensive phase of the rendering pipeline.
Post reply on HN