5

I have an animation and JS for alternating 2 divs and change their background images (from an array of a few dozens images), sort of interchangeable divs. Everything works just fine, however when the animation runs I can see that my CPU is at 100%. At first I thought it might be due to setInterval, however when I changed the code from alternating the images to just increase a number with each iteration and log it to console - I saw dramatic CPU overload decrease, of about 40-50%. So I understood it might be due to animation.

Here's my HTML code:

<div class="wallpaper wallpaper-1" id="wallpaper-1"></div> <div class="wallpaper wallpaper-2" id="wallpaper-2"></div>

CSS:

.wallpaper { width: 100%; height: 100%; position: absolute; opacity: 0; background-repeat: no-repeat; background-position: center; background-size: cover; -webkit-transform: translateZ(0); -webkit-animation-timing-function: linear; } .animate { -webkit-animation-name: fadeInOut; -webkit-animation-duration: 6s; } @-webkit-keyframes fadeInOut { 0% { opacity: 0; -webkit-transform: scale(1); } 16% { opacity: 1; } 90% { opacity: 1; } 100% { opacity: 0; -webkit-transform: scale(1.1); } }

And JS that makes it all tick:

Wallpapers.get().then(function(list) { var wp1, wp2, divs = [], path, bgs = [], counterBgs = 0, bgsLength, currentId, doInterval; wp1 = document.getElementById('wallpaper-1'); wp2 = document.getElementById('wallpaper-2'); divs = [ wp1, wp2 ]; path = 'assets/img/wallpapers/'; bgs = list.data; bgsLength = bgs.length; //Preload images for(var i = 0; i < bgsLength-1; i++) { var wp = new Image(); wp.src = path+list.data[i]; } function manageBg() { setInterval(function(){ doInterval(); }, 4000); } doInterval = function doInterval() { currentId = counterBgs % bgsLength; if (counterBgs % 2 === 0) { wp1.style.backgroundImage = "url(" + path + bgs[currentId] + ")"; wp1.classList.add('animate'); wp1.style.zIndex = 1; wp2.style.zIndex = 0; setTimeout(function() { wp1.classList.remove('animate'); }, 5950); } else { wp2.style.backgroundImage = "url(" + path + bgs[currentId] + ")"; wp2.classList.add('animate'); wp1.style.zIndex = 0; wp2.style.zIndex = 1; setTimeout(function() { wp2.classList.remove('animate'); }, 5950); } counterBgs++; }; doInterval(); manageBg(); });

Any ideas how to reduce the CPU overload?

Improve this question
23
  • 1
    i just noticed you are using (transform: translateZ(0);) to put the wallpapers on the hardware layer. have you tried without? Commented Feb 21, 2016 at 8:46
  • 1
    @Tasos Yeah, I tried to move the load to GPU by adding transform: translateZ(0);. It somewhat helped, the load was reduced by 3-4% in average. Without it the CPU was constantly on 100%. Commented Feb 21, 2016 at 8:51
  • 1
    I can run a similar animation on chrome and firefox and edge, without the prefixes, all three use about 3% CPU at most on a 5 year old 4 core AMD with a low to mid spec ATI video card - the only difference with my code is the complete lack of setInterval/setTimeout - I use animationend event to trigger the next image and never have to bother with z-index at all Commented Feb 21, 2016 at 9:15
  • 1
    as promised - jsfiddle.net/wmkvdd4x Commented Feb 22, 2016 at 7:23
  • 1
    @Tasos False. Only the last property will overwrite a former, doesn't matter which one is prefixed. E.g. -moz-border-radius: 3px; border-radius: 2px; -> W3 standard is used, border-radius: 2px; -moz-border-radius: 3px; -> Mozilla prefix is used. Also, for experimental features some browsers still rely on their vendor-prefixed implementation. This differs per property. Commented Jul 8, 2016 at 10:30

1 Answer 1

Reset to default
3

The answer is property of css.

will-change is a property that optimizes animations by letting the browser know which properties and elements are just about to be manipulated, potentially increasing the performance of that particular operation.

Article Source: will-change - css tricks

The will-change property will use Hardware Acceleration in order to reduce load of your CPU and allocating your CSS3 animation/transformation to the GPU.

The Old: The translateZ() or translate3d() Hack

For quite some time now, we’ve been using what has been known as the translateZ() (or translate3d()) hack (sometimes also called the null transform hack) to trick the browser into pushing our animations and transforms into hardware acceleration. We’ve been doing that by adding a simple 3D transformation to an element that will not be transforming in three-dimensional space. For example, an element that’s animated in two-dimensional space can be hardware-accelerated by adding this simple rule to it:

transform: translate3d(0, 0, 0);

Hardware-accelerating an operation results in the creation of what is known as a compositor layer that is uploaded to and composited by the GPU. However, force-hacking layer creation may not always be the solution to certain performance bottlenecks on a page. Layer creation techniques can boost page speed, but they come with a cost: they take up memory in system RAM and on the GPU (particularly limited on mobile devices) and having lots of them can have a bad impact (especially on mobile devices), so they must be used wisely and you need to make sure that hardware-accelerating your operation will really help the performance of your page, and that a performance bottleneck is not being caused by another operation on your page.

In order to avoid layer-creation hacks, a new CSS property has been introduced, that allows us to inform the browser ahead of time of what kinds of changes we are likely to make to an element, thus allowing it to optimize how it handles the element ahead of time, performing potentially-expensive work preparing for an operation such as an animation, for example, before the animation actually begins. This property is the new will-change property.

The New: The Glorious will-change Property

The will-change property allows you to inform the browser ahead of time of what kinds of changes you are likely to make to an element, so that it can set up the appropriate optimizations before they’re needed, therefore avoiding a non-trivial start-up cost which can have a negative effect on the responsiveness of a page. The elements can be changed and rendered faster, and the page will be able to update snappily, resulting in a smoother experience.

For example, when using CSS 3D Transforms on an element, the element and its contents might be promoted to a layer, as we mentioned earlier, before they are composited in (drawn onto the screen) later. However, setting up the element in a fresh layer is a relatively expensive operation, which can delay the start of a transform animation by a noticeable fraction of a second, causing that noticeable “flicker”.

In order to avoid this delay, you can inform the browser about the changes some time before they actually happen. That way, it will have some time to prepare for these changes, so that when these changes occur, the element’s layer will be ready and the transform animation can be performed and then the element can be rendered and the page updated in quickly.

Using will-change, hinting to the browser about an upcoming transformation can be as simple as adding this rule to the element that you’re expecting to be transformed:

will-change: transform;

You can also declare to the browser your intention to change an element’s scroll position (the element’s position in the visible scroll window and how much of it is visible within that window), its contents, or one or more of its CSS property values by specifying the name of the properties you’re expecting to change. If you expect or plan to change multiple values/aspects of an element, you can provide a list of comma-separated values. For example, if you’re expecting the element to be animated and moved (its position changed), you can declare that to the browser like so:

will-change: transform, opacity;

Specifying what exactly you want to change allows the browser to make better decisions about the optimizations that it needs to make for these particular changes. This is obviously a better way to achieve a speed boost without resorting to hacks and forcing the browser into layer creations that may or may not be necessary or useful.

Article Source - Everything You Need to Know About the CSS will-change Property

Your css will be

.wallpaper { width: 100%; height: 100%; position: absolute; opacity: 0; background-repeat: no-repeat; background-position: center; background-size: cover; will-change: transform, opacity; -webkit-animation-timing-function: linear; } .animate { -webkit-animation-name: fadeInOut; -webkit-animation-duration: 6s; } @-webkit-keyframes fadeInOut { 0% { opacity: 0; -webkit-transform: scale(1); } 16% { opacity: 1; } 90% { opacity: 1; } 100% { opacity: 0; -webkit-transform: scale(1.1); } }

Other Useful Sources:

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

That's quite a big quote. Try to extract what is useful for this specific case. Why would will-change help this user.
The whole thing is useful here so can i remove the quotes? Just will mention source in the bottom!!
@Igal Please try this and let us know your CPU load

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.