Are CSS3 Properties Like Animate Too CPU Intensive

Are CSS3 properties like animate too CPU intensive?

Avoid using box-shadow & text-shadow. Don't try and animate the whole page, or the body element and use translate3d, scale3d, rotate3d as they are hardware accelerated on computers and mobile devices. As stated above, avoid the OVERUSE of animating properties. I however doubt that one or even four infinitely animated elements will slow down your page.

Improving the Performance of your HTML5 App

UPDATE

Beware! Browsers are now dropping hardware acceleration for transform-3D properties. You will have to use other methods to optimize your apps as of now and in the future.

CSS keyframe animation CPU usage is high, should it be this way?

Yes, this is normal because you have several infinite-loop animations on the page. The CPU is therefore continually doing work while these elements are rendered. There is a "magic" property that will significantly cut-down the CPU usage and that is:

transform: translateZ(0);

This will composite the elements into their own layers (by tricking the browser into thinking it will be doing 3D transforms) and the browser should, in most cases, take advantage of GPU acceleration, lessening the burden on the CPU. For me this cut it down by about 20% (almost half).

To read more about this technique take a look at: http://ariya.blogspot.com/2011/07/fluid-animation-with-accelerated.html

Additionally, the more keyframes you have in the animation, the more taxing it will be as well. Just try the animation with the middle keyframe cut out and you will see another substantial (~10-12%) drop in CPU usage.

Lastly, not all properties are equal -- box-shadow is much harder for the browser to animate smoothly than, say, background-color. Leaving all of the keyframes intact but dropping the box-shadow property, using the translateZ(0) trick had my CPU usage hovered at only 10-11%.

As much as it pains me to say this, for infinite-loop animations an animated .gif is going to perform much, much better than CSS3 in the current state of browser animation, especially if you plan for many of them to remain rendered on the page for some time.

Update 2017:

For those still finding their way to this question and answer, translate3d(0, 0, 0) provides the same benefit as translateZ(0), you're just also setting translateX() and translateY() at the same time. Please ignore the comment by @Farside as he uses translate3d(X, Y, Z) in his demo but does not compare it to translate(X, Y), which would show that using this technique still makes a significant difference.

According to this question, some people have found better performance across all browsers, especially Chrome, with transform: rotateZ(360deg).

CPU Usage high for my CSS Animation. Can I use the GPU to lessen the burden?

Maybe something like this will work? Instead of directly animating the background image, which requires a repaint for each frame, try using transform: translate3d() on a pseudo element. The included z-axis in translate3d() will force GPU rendering too!

@keyframes shimmerBackground {
  0% { transform: translate3d(-400px, 0, 0) }
  100% { transform: translate3d(900px, 0, 0) }
}

.skeleton:empty{
  width: 500px;
  height: 40px;
  position: relative;
  overflow: hidden;
  background-color: #e4e3e3;
}

.skeleton:empty::before {
  content: "";
  display: block;
  width: 400px;
  height: 100%;
  position: absolute;
  left: 0;
  top: 0;
  background: no-repeat #e4e3e3;
  background-image: linear-gradient(to right, #e4e3e3 0, #c7c6c6 20%, #e4e3e3 40%, #e4e3e3 100%);
  animation-duration: 1s;
  animation-timing-function: linear;
  animation-iteration-count: infinite;
  animation: shimmerBackground 1s linear infinite;
}

CSS3 filter performance & CPU usage: Why do certain filters tax the CPU?

You'll notice that the only time the performance is hit hard is when you either use blur or drop-shadow. If you play with any of the other filters there is very little cpu usage or any indication of a performance hit.

The first thing to understand is that not all filters are created equal.

Most filters modify pixels on a 1:1 level which is a relatively straight forward calculation.

However when you introduce anything with a "blur" or "shadow" it may no longer be a 1:1 calculation.

Say you use the radius parameter and set it to 5px. You now need to look at 5x the amount of pixels to calculate what the blur should look like.

When you compound this with other filters on top of this the calculation required increases.

Modern browsers are able to utilize the GPU to help with these calculations to make the process faster but you'll notice devices with weak GPU's suffering.

So to answer your question specifically. The CPU isn't running after the filter is applied, it's actually still in the process of calculating! When you put in crazy values like the example allows you to (e.g. a radius of 100px) you can imagine how intensive that calculation will be on the CPU.

Here is a quick guideline on performance for CSS filters:

• grayscale / fast
• sepia / fast
• saturate / fast
• hue-rotate / fast
• invert / fast
• opacity / variable
• brightness / fast
• contrast / fast
• blur / slow
• drop-shadow / slow
• url() / variable

How can I animate infinite marker movement down an SVG path without very high CPU usage?

It seems indeed that animating the stroke-dashoffset attribute causes a lot of calculations. The original example causes a CPU usage at around 50% when I open it in Firefox.

There's another approach that seems to give better results: manually increment the stroke-dashoffset and loop that using setInterval. Here's a proof of concept:

http://bl.ocks.org/kmandov/raw/a87de2dd49a21be9f95c/

Here's how I update the dashoffset:

var lines = d3.selectAll('.flowline');

var offset = 1; 
setInterval(function() {
  lines.style('stroke-dashoffset', offset);
  offset += 1; 
}, 50);  

I know that it doesn't look very good but it (surprisingly) performs a lot better than relying on css animations or transitions. In Firefox I now get CPU usage at about 15%.

I can imagine that this approach won't perform very well if you have a lot of links, because the update will take too long. But maybe it's a viable hack for simpler use cases where you animate linearly a fixed amount of links.

---

Related Topics