Firefox consumes high CPU with background-size: cover

RESOLVED FIXED in mozilla35



6 years ago
5 years ago


(Reporter: kaz.namba, Unassigned)


(4 keywords)

19 Branch
Dependency tree / graph
Bug Flags:
firefox-backlog -

Firefox Tracking Flags

(firefox20-, firefox21-, firefox22-, firefox26 affected, firefox27 affected, firefox28 affected, firefox29 affected, firefox-esr17 unaffected, firefox-esr24 affected)



(1 attachment, 2 obsolete attachments)



6 years ago
Posted file Reproducible sample file (obsolete) —
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130215130331

Steps to reproduce:

When CSS background-size property has cover or contain with several width/height pairs, Firefox starts to hog CPU.

Reproducible: Always
I tested on Windows 7 and Mac OS X 10.8.2 with the HTML file attached, and it happened always on Windows 7.

Actual results:

By enabling the checkbox in the HTML file attached, the CPU usage jumps to over 50%, and gets back to normal if you uncheck it.
Sometimes I saw the images shakes up and down to right and left.


6 years ago
Component: Untriaged → General
OS: Mac OS X → Windows 7
Attachment #719471 - Attachment mime type: text/plain → text/html
Component: General → Untriaged
I can not reproduce a high cpu usage with Firefox19 on win7 and i tried it with and without hardware acceleration

Comment 2

6 years ago
With updated version, I added 2 more images and lots of elements.
I can see a distinguishable result when I set the checkbox on and scrolled the page up and down several times.
I tried on another Win 7 32bit, Win 7 64bit, Win 7 64bit on VirtualBox, and Win Vista machines and it happened always.
Attachment #719471 - Attachment is obsolete: true


6 years ago
Attachment #719829 - Attachment mime type: text/plain → text/html

Comment 3

6 years ago
I confirm the high CPU use with "background-size: cover" enabled in the testcase. You can use a simple widget on Windows to display the CPU use? Checking the box is enough to increase CPU use, not need to scroll up/down.

Regression range:

Surely an issue with layer.
Ever confirmed: true

Comment 4

6 years ago
Regression window(m-i)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121017083113
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121017084912

Suspected :
 Bug 795940 - Part 2 - Re-enable high-quality downscaling. r=jlebar

image.high_quality_downscaling.enabled = false helps.


6 years ago
Component: Untriaged → ImageLib
Product: Firefox → Core

Comment 5

6 years ago
Regression with force image.high_quality_downscaling.enabled = true is as follow.

Regression window(m-i)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120928090936
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120928100437

Suspected: Bug 486918
Blocks: 486918
No longer blocks: 795940
This is currently a single, likely uncommon web regression without significant user impact. We'd accept a low risk fix, but don't need to track the bug.
Assignee: nobody → joe

Comment 7

6 years ago
(In reply to Alex Keybl [:akeybl] from comment #6)
> This is currently a single, likely uncommon web regression without
> significant user impact. We'd accept a low risk fix, but don't need to track
> the bug.

I think this causes the significant user impact because Firefox hogs CPU and the rendering goes slow by simply setting this CSS property. The CSS property is widely known to web programmers and used everywhere. In fact, I'm developing a web-application for enterprise use and using the CSS property many times in the application. High CPU usages are reported from my users that's why I came up here.
I'd like to ask you to fix this problem as soon as you can.

Comment 8

6 years ago
Confirming this issue also on Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0. Toggling the image.high_quality_downscaling.enabled flag (setting it to false). Drops CPU % to 0, with it enabled jumps to 100% and you can also visually see the background-image jumping / shaking / vibrating.

Comment 9

6 years ago
Posted file Simple testcase (obsolete) —
Simpler testcase showing the issue, it is important that the image points to the same src(), floating next to each-other and one is smaller / bigger than the other.


6 years ago
Attachment #723906 - Attachment mime type: text/plain → text/html

Comment 10

6 years ago
See also Bug 732150.

Comment 11

6 years ago
The issue caused by height property also. 

If height is 100% and not in px then CPU load get to 100%


6 years ago
Duplicate of this bug: 884497
Assignee: joe → nobody

Comment 13

6 years ago
I'm also impacted by this bug. CPU high when "background-size: 100%" for height is used. Please~~~ this is very problematic. My tree diagram needs stretchable images to get proper style.

Comment 14

6 years ago
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0

I've also come across what appears to be this bug.

In my case, the behaviour is exhibited by a (fairly large) background image on a div with "background-size: contain", but only when it also has a background-position other than 0 0.
As well as high CPU, I can see the scaled image flicker/jitter/jiggle, like it's being repeatedly resized using slightly different parameters.

The aforementioned about:config parameter instantly halts the problem for me, and reactivating resumes the jittering.

However, if I use FireBug to turn off the element's background-image CSS, and then turn it back on, the image behaves itself, and CPU usage remains low. This remains true even if the about:config setting is thence toggled off/on.

Comment 15

6 years ago
Further to my prior comment, I've just discovered that the jittering only seems to occur when the resized image is also being displayed elsewhere on the same page.
In my case it's as another background-image, on a smaller label element.

Comment 16

6 years ago
Additional problem scenario.

Excessive CPU (30-40%) on Win7 when specifying a CSS background-size which is not an integer divisor of the original image size.

Eg, the background-image is 100x100 pixels, and a CSS background-size is specified as something like 60px 60px

The images are resized properly and look great but the CPU loads permanently while the page is visible.

Strangely, 50x50 works fine.

Comment 17

5 years ago
Firefox consumes high cpu with table cell background image set with css to:
[...] td{background-size: 100% 100%;}
Check this on - try cut line '38 and it will work OK without that

Comment 18

5 years ago
I can confirm this exists in FF26, it seems to be based on visible elements that have background-size set and increases the more that are visible.

Applying the CSS style: "image-rendering: -moz-crisp-edges" to an element with background-size set will drop the cpu usage but causes the image to have no smoothing applied.


5 years ago
Keywords: power

Comment 19

5 years ago
Comment on attachment 723906 [details]
Simple testcase

Attachment #723906 - Attachment is obsolete: true


5 years ago
Blocks: 953037

Comment 20

5 years ago
It also happen in my browser, Firefox 26 for Ubuntu. I've been investigating the issue and it only occurs if:

1. It's applied to an element which size depends on its contained text (inline?), for example a <a> tag. If you assign a fixed size to the element the problem stops.

2. The contained text must be over the background. For example if I use a background-size contain no-repeat with an small image and then I move the image outside the text area by applying a padding then the problem stops too.

Comment 21

5 years ago
I have the same problem using an img tag resized, duplicated in Firefox 26.0 on Windows 7 SP1 (all updates up to 01/28/2014).

On my case it gets solved when I remove the duplicated use of the image, explanation: I have a list of images and a panel where I show it at large, on a early web dev stage I did not have still the thumbnail images created and I was using the same image on both img tags, on that case the problem arise with with a high CPU usage and flicker/jitter/jiggle on both images.

The images sizes was 922x692px, 10 in total on test.

I get it fixed avoiding the situation but there are cases, like icons or some galleries, that is required to have duplicated uses of the same image on sizes that may be not 'optimal' (some previous comments report as works fine with 2x, 3x, 1/2, etc. sizes what has sense) like adjusting to screen size, mostly on mobile.

I hope this helps.

Comment 22

5 years ago
I can confirm this problem on FF27. Also want to admit that it occurs if:
1) there are 2 or more resized images of 1 source - (i.e 2 divs with different sizes and same background-image)
2) these images must be taken from cache or data:image in other case it will not be reproduced

Comment 23

5 years ago
We're running into the same issue here and we have yet to come up with an easy workaround for this issue. I'm starting to investigate ways to use a combination of divs and image tags (divs and canvas elems just displaying images) to get the behavior we need, but it's clearly not a joyous thing to have to go down this path of reinventing the wheel to to work around a FF-only bug that has been around for over a year. :(

Our use case:
1. Have a set of divs on a page where each div has the following css:
background-size: cover;
background-repeat: no-repeat;
background-position: center;

2. Have another area on the page containing more divs that are using a subset of the same images used by the divs in #1. These divs have the following CSS:
background-size: auto 120px;
background-repeat: repeat-x;

And like everyone else on this thread has already said, whenever these images end up getting used multiple times, we get the jitter + CPU usage (~50% on each of my machine's four cores). :(

I also tested Pete's suggestion of applying the CSS style: "image-rendering: -moz-crisp-edges", but the non-smoothed images look terrible, so we can't use that as a work around.

Comment 24

5 years ago
I was just investigating this issue and noticed that the flicker/jitter appears to be the image-rendering rapidly switching back and forth between -moz-pixelated and -moz-crisp-edges.

The value of image-rendering in the inspector does not change, but the visual appearance of the image scaling itself during the jitter looks to be alternating between the two modes.  Perhaps this will help someone finally track down such a longstanding and pervasive issue.

Comment 25

5 years ago
+1 for prioritizing this bug.  It is quite painful for our Firefox users right now.

A tip for other web devs who are trying to work around this bug: You can enable the "Highlight painted area" tool (the paintbrush icon at the top of Web Inspector) to help track down the problem elements.

Thanks for the tip to set `image-rendering: -moz-crisp-edges;` - it can be placed on the body for convenience.  That always stops the repaints but it is quite ugly.

In our case, we don't use `background-size: cover;` but we do use multiple icons from one spritesheet png with different values of `transform: scale(0.NNN);`  Removing those transform properties prevents 90% of the repaints.  (The other 10%?  Maybe there are some more scale() transforms which I missed...)  (I am currently debugging on Firefox 28 under Ubuntu.)

If it's difficult to entirely prevent the constant repaints, please just slow them down a bit.  ;-)

Comment 26

5 years ago
Just setting image.high_quality_downscaling.enabled = false in about:config solves this and other high CPU bug.

Comment 27

5 years ago
Seeing this in FF29 Linux ( Ubuntu ) 64bit with a scaled sprite image background. 

Using this css technique ( )

Comment 28

5 years ago
This is not only a nuisance for developers but also degrades the user experience on affected sites (slow scrolling, reduced battery runtime, etc.).
Flags: firefox-backlog?
I agree that we should fix this, but it's not a Firefox front-end bug, so not eligible for being in our backlog.
Flags: firefox-backlog? → firefox-backlog-

Comment 30

5 years ago

Saying that the bug is not your problem is not a solution. Please assign this bug to the appropriate people who will understand how ridiculous it is that this bug has gone unfixed for so long when it affects all users, as Florian correctly pointed out. It's even listed as blocking a major issue. Thank you for your help.
The bug is assigned to the appropriate product+component already.  All Gavin did was point out that firefox-backlog flag is used only for Firefox front-end bugs and as such is not a relevant flag in this case.

Comment 32

5 years ago
This affects users of Phabricator:

I can confirm that at least for Firefox 29 on Fedora 20. The "platform" field should be adjusted.


5 years ago
OS: Windows 7 → All
Hardware: x86 → All
Summary: Firefox 19 on Windows consumes CPU with background-size: cover → Firefox consumes high CPU with background-size: cover
It looks like RequestScale refuses to do a high-quality scale if the image is being used in multiple places.

In this case the mLockCount is 1, because we only have a single imgRequestProxy, belonging to the nsStyleImage style data.

However this style data is used for multiple elements of different sizes.

As we paint each element we kick off a new high-quality downscale task, cancelling the existing one. Only the last element actually gets a task running to completion. When it completes we schedule a new paint, and paint all the elements again (since they all got invalidated by the decode finishing). The high-quality downscale doesn't match the first element (since it was generated for the last element) so we discard it and start the process again..

Repeat downscaling all the image forever.
Bug 977459 tracks fixing that issue.
Bug 977459 is a metabug; this specific issue is fixed by one of its blockers, bug 1060200. A patch is already up in that bug and green on try, so expect a fix for this to land very soon.
Depends on: 1060200
No longer depends on: 977459
This was fixed by bug 1060200. I just checked, and I can't reproduce the issue anymore.
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 37

5 years ago
Which Firefox stable version should end up containing this fix?
Can I verify it using tomorrow's nightly compose?

Comment 38

5 years ago
(In reply to Kamil Páral from comment #37)
> Which Firefox stable version should end up containing this fix?
> Can I verify it using tomorrow's nightly compose?

You need to install the latest Nightly to test that:

Comment 39

5 years ago
I have verified that this is fixed with today's nightly compose. I'd love to know whether this is going to be included in Firefox 33?

Comment 40

5 years ago
(In reply to Kamil Páral from comment #39)
> I'd love to
> know whether this is going to be included in Firefox 33?

Seth said it's not possile because the code changes are too massive, see


5 years ago
Duplicate of this bug: 1087268
Target Milestone: --- → mozilla35

Comment 42

5 years ago
Here's a video recording of this bug:

Comment 43

5 years ago
(In reply to gnatko from comment #42)
> Here's a video recording of this bug:

It's fixed in FF35.

Comment 44

5 years ago
Any clue on when the 35 becomes the stable release?

Mine says 33.1.1 and calls itself the latest version.

Comment 45

5 years ago
(In reply to gnatko from comment #44)
> Any clue on when the 35 becomes the stable release?
> Mine says 33.1.1 and calls itself the latest version.
From [1], Firefox 35 is scheduled to be released on January 13, 2015. More specifically, 25% of users will be offered the update on January 13, and if no major problems are found the update will be pushed to all users on January 16 [2] (but you can manually update before then).

You need to log in before you can comment on or make changes to this bug.