Closed Bug 846315 Opened 9 years ago Closed 7 years ago

Firefox consumes high CPU with background-size: cover


(Core :: ImageLib, defect)

19 Branch
Not set



Tracking Status
firefox20 - ---
firefox21 - ---
firefox22 - ---
firefox26 --- affected
firefox27 --- affected
firefox28 --- affected
firefox29 --- affected
firefox-esr17 --- unaffected
firefox-esr24 --- affected


(Reporter: kaz.namba, Unassigned)



(4 keywords)


(1 file, 2 obsolete files)

Attached 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.
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
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
Attachment #719829 - Attachment mime type: text/plain → text/html
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
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.
Component: Untriaged → ImageLib
Product: Firefox → Core
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
(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.
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.
Attached 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.
Attachment #723906 - Attachment mime type: text/plain → text/html
See also Bug 732150.
The issue caused by height property also. 

If height is 100% and not in px then CPU load get to 100%
Duplicate of this bug: 884497
Assignee: joe → nobody
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.
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.
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.
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.
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
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.
Keywords: power
Comment on attachment 723906 [details]
Simple testcase

Attachment #723906 - Attachment is obsolete: true
Blocks: 953037
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.
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.
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
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.
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.
+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.  ;-)
Just setting image.high_quality_downscaling.enabled = false in about:config solves this and other high CPU bug.
Seeing this in FF29 Linux ( Ubuntu ) 64bit with a scaled sprite image background. 

Using this css technique ( )
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-

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.
This affects users of Phabricator:

I can confirm that at least for Firefox 29 on Fedora 20. The "platform" field should be adjusted.
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.
Depends on: 977459
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.
Closed: 7 years ago
Resolution: --- → FIXED
Which Firefox stable version should end up containing this fix?
Can I verify it using tomorrow's nightly compose?
(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:
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?
(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
Duplicate of this bug: 1087268
Target Milestone: --- → mozilla35
Here's a video recording of this bug:
(In reply to gnatko from comment #42)
> Here's a video recording of this bug:

It's fixed in FF35.
Any clue on when the 35 becomes the stable release?

Mine says 33.1.1 and calls itself the latest version.
(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.