[rasz]

On one hand super cool due to tricks employed, on the other CSS animations tend to be very power hungry

https://www.bryanbraun.com/after-dark-css/all/rainstorm.html

takes <40% of idle low range gaming GPU = nothing, but 30% of one gaming 4GHz CPU thread, what is going on there? Chrome GPU process jumps between 20 an 40% while sliding 6 bitmaps around, something you could even do on a Virge in 1996.

Some time ago I noticed an older 3GHz i5 laptop, otherwise perfectly usable, would start to struggle decoding h264 webcam stream because webmaster decided to use CSS animation for a scrolling title bar superimposed over video feed.

[nine_k]

That's why it's a good idea to develop for and test on outdated and underpowered hardware, or at least an emulator of it.

Many of your customers won't have top-notch systems.

[rasz]

This might be a situation where we need to publicly shame Google into optimizing Chrome. Something akin to 1998 CSS1 Test Suite ACID tests https://thehistoryoftheweb.com/the-rise-of-css/ making a case for IE/Netscape fixing their bad implementations.

[brundolf]

I'd assume CSS animations would be much more efficient than JS-based animations because they can be entirely comprehended and executed by native code

I wonder if there's some unnecessary reflow going on here? (reflow forces animations to happen on the CPU instead of the GPU)

[rasz]

Me too. They were designed in a way any modern hardware Accelerated GUI 2D/3D engine should be able to perform them entirely in hardware with CPU just pre filling command lists. When I researched the problem I found they might be much leaner on Safari which isnt surprising considering they were proposed by WebKit in 2007, and Apple (in its fight vs Flash) would want them optimized for phone battery. On Chrome they are second class citizen. There isnt even a visibility check - CSS animation will run on 100% obscured or offscreen elements.

You can edit

    .rain {top: -4800px;

to top: 4800px, CPU utilization doesnt change. It sure feels like some procedure spinning in place burning CPU doing nothing. Just a reminder, Rain is implemented in a clever way, its blitting one 800x600 bitmap 6 times per animation frame to a frame buffer. Worst case scenario its 600MB/s fillrate done entirely by hardware accelerated 2D engine, yet Chrome is using ~30% of one 4GHz CPU core doing this.

Hmm, maybe its reading buffer back from GPU and compositing in software? I did an experiment and deleted 5 of the 6 DIVs reducing load to 100MB/s fillrate and CPU utilization didnt even budge .... so Chrome is doing something stupid like reading GPU buffer back to main memory and pushing it to GPU again. This explains why my older i5 laptop was so loaded by stupid tiny text scroll.

[bryanbraun]

Original dev here. I took another look at these and I found a lot of animations that we could convert to transforms to improve performance. I just created a new issue here: https://github.com/bryanbraun/after-dark-css/issues/9