Wait, this is supposed to be an improvement? 6% CPU for a lame animation?
Don't animate height
211–220 of 276 posts
Re: Don't animate height
#212Earlier quoted context omitted.
I wish. But some sites we are stuck with. EG: bank, HR App, etc.
How about not living in society and instead going into the wild?
Re: Don't animate height
#213Just 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 .
Re: Don't animate height
#214Earlier quoted context omitted.
Is there a good way to learn techniques like this from first principles other than trying to become an employed frontend dev?
You need to think about what the browser is actually doing when it displays a web page. You need to think about what happens when you type the URL in and what the browser is doing conceptually. If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well. There is an old school talk by Nikolas Zakas on JavaScript Performance from 2009 which while some of it is…
No. No it will not. Nothing in 2D graphics will help you understand things like "simple animation required full layout re-calculation and re-painting of the entire page"
Re: Don't animate height
#215Earlier quoted context omitted.
You need to think about what the browser is actually doing when it displays a web page. You need to think about what happens when you type the URL in and what the browser is doing conceptually. If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well. There is an old school talk by Nikolas Zakas on JavaScript Performance from 2009 which while some of it is…
> If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well. No. No it will not. Nothing in 2D graphics will help you understand things like "simple animation required full layout re-calculation and re-painting of the entire page"
Re: Don't animate height
#216Just 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?
Re: Don't animate height
#217Re: Don't animate height
#218Here'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…
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.
Re: Don't animate height
#219Ok, but we can all agree that even 6% constant CPU usage is way too high for a note-taking app, right?
Re: Don't animate height
#220Earlier quoted context omitted.
> Just wrap it in a container with fixed height and "overflow: hidden". That's a fix for a webdev who cares, not a fix for a browser vendor as GP was alluding to.
I don't understand how you'd fix this, in general, for the browser: the browser can't just assume certain animations will never affect layout.
Like the example from the linked article, there's one animation involved essentially and if the browser does the hard work for the entire length of one animation cycle and no layout ever changes, just assume it never will? It would have to have a bunch of edge cases to handle correctly I'm sure though.