Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Animations like this shouldn’t require much CPU load. The actual 2D translation can be done on hardware providing no reflow occurs.


What is the correct way to check? I see 8% on a chrome thread and 2% on other chroem thread with only this page opened. A static page should use 0% . This percentages are per core.


The page regrettably is rendering animations in an SVG. In my experiments in the past, all browsers tended to optimise SVG animation, of all kinds, poorly. (CSS, animateMotion, JS - well, JS always performs badly obviously but..).

I think it'd be worth trying to translate this to CSS on text in a web page and see if the performance issues are still there. One can do it transparently these days with CSS filters. Or just draw against same colour as page background.

In fact, I think I'm going to give this a try. Will update here, but might take a while to get to it. I also wonder if it could be done more simply. this is basically just slices of offset text right? Also, those clip rects are pretty large. Wonder if that would impact browser texture allocation.


So my question is in general, animate infinite , is it a bad idea for a simple web page ? My experience was me having to put an emergency fix live because someone made such a css change that had for some reason very noticeable impact on OSX but not on Windows and Linux (though I could see the CPU usage in Linux there was no visible lag).

I also remember a big issue with a blinking cursor, so I am thinking why is such heavy animation APIs not coming with giant warnings.


It's really really really browser and hardware dependant. https://m8y.org/tmp/testcase425.xhtml from 2018 is a simple effect with 2 translucent gradients. Was getting 200% (2 cores) CPU usage in Chrome on Windows, but like 15% in Firefox. Pretty much a case of hardware acceleration. OSX performed well in Safari but not Firefox and Chrome... Linux depended a lot on whether one force-enabled hardware acceleration which was off by default.

Overall I'd say if your web page doesn't need continuous animation, and you're worried about battery life or stutteriness or whatever, maybe don't use it?

It has gotten a lot better though. Not for SVG though, at least not last time I checked, and forget about SVG animated fonts unless you don't mind running CPU at 100% nonstop. :)


> providing no reflow occurs

CSS generally does not trigger reflow, including in this case. More: https://gist.github.com/paulirish/5d52fb081b3570c81e3a


So in this case it triggers repaints, or maybe I am wrong i opened only this page in Chrome, profiled it then deleted the item and profiled it again

Also in my Process manager I see 2 chrome process with 5% and 7=8% usage witht he animated element and if I remove the elemtn I see only 1 process with 2% usage (weird static page still uses CPU, maybe there is still some other crap somewhere I had no adblocking on.

So far the only way I found to debug such performance issue was to start deleting elements until the CPU usage in Process manager drops I wish I knew a better way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: