Closed
Bug 846315
Opened 12 years ago
Closed 10 years ago
Firefox consumes high CPU with background-size: cover
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
FIXED
mozilla35
People
(Reporter: kaz.namba, Unassigned)
References
Details
(4 keywords)
Attachments
(1 file, 2 obsolete files)
(deleted),
text/html
|
Details |
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.
Updated•12 years ago
|
Attachment #719471 -
Attachment mime type: text/plain → text/html
Updated•12 years ago
|
Component: General → Untriaged
Comment 1•12 years ago
|
||
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:
m-c
good=2012-10-17
bad=2012-10-18
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dac5700acf8b&tochange=cb573b9307e5
Surely an issue with layer.
Status: UNCONFIRMED → NEW
tracking-firefox20:
--- → ?
tracking-firefox21:
--- → ?
tracking-firefox22:
--- → ?
Ever confirmed: true
Keywords: perf,
regressionwindow-wanted
Comment 4•12 years ago
|
||
Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/396742c90b0a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121017083113
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/4eb7de485ee8
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121017084912
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=396742c90b0a&tochange=4eb7de485ee8
Suspected :
Bug 795940 - Part 2 - Re-enable high-quality downscaling. r=jlebar
FYI,
image.high_quality_downscaling.enabled = false helps.
Updated•12 years ago
|
Blocks: 795940
Keywords: regressionwindow-wanted → regression
Updated•12 years ago
|
Component: Untriaged → ImageLib
Product: Firefox → Core
Comment 5•12 years ago
|
||
Regression with force image.high_quality_downscaling.enabled = true is as follow.
Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/eda2891c545b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120928090936
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/92530b29ac24
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120928100437
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=eda2891c545b&tochange=92530b29ac24
Suspected: Bug 486918
Comment 6•12 years ago
|
||
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.
Comment 8•12 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•12 years ago
|
||
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
Comment 10•12 years ago
|
||
See also Bug 732150.
Comment 11•12 years ago
|
||
The issue caused by height property also.
If height is 100% and not in px then CPU load get to 100%
Updated•11 years ago
|
Assignee: joe → nobody
Comment 13•11 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•11 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•11 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•11 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•11 years ago
|
||
Firefox consumes high cpu with table cell background image set with css to:
[...] td{background-size: 100% 100%;}
Check this on urfu.pl - try cut line '38 and it will work OK without that
Comment 18•11 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.
Updated•11 years ago
|
status-firefox26:
--- → affected
status-firefox27:
--- → affected
status-firefox28:
--- → affected
status-firefox29:
--- → affected
status-firefox-esr17:
--- → unaffected
status-firefox-esr24:
--- → affected
Comment 19•11 years ago
|
||
Comment on attachment 723906 [details]
Simple testcase
404
Attachment #723906 -
Attachment is obsolete: true
Comment 20•11 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•11 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•11 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•11 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-image:url('urlgoeshere');
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-image:url('urlgoeshere');
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•11 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•11 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•11 years ago
|
||
Just setting image.high_quality_downscaling.enabled = false in about:config solves this and other high CPU bug.
Comment 27•11 years ago
|
||
Seeing this in FF29 Linux ( Ubuntu ) 64bit with a scaled sprite image background.
Using this css technique ( https://gist.github.com/apauly/7917906 )
Comment 28•11 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?
Comment 29•11 years ago
|
||
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•11 years ago
|
||
@Gavin
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.
Comment 31•11 years ago
|
||
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•11 years ago
|
||
This affects users of Phabricator:
https://secure.phabricator.com/T5211
I can confirm that at least for Firefox 29 on Fedora 20. The "platform" field should be adjusted.
Updated•11 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
Comment 33•10 years ago
|
||
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.
Comment 34•10 years ago
|
||
Bug 977459 tracks fixing that issue.
Comment 35•10 years ago
|
||
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.
Comment 36•10 years ago
|
||
This was fixed by bug 1060200. I just checked, and I can't reproduce the issue anymore.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 37•10 years ago
|
||
Which Firefox stable version should end up containing this fix?
Can I verify it using tomorrow's nightly compose?
Comment 38•10 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: https://nightly.mozilla.org/
Comment 39•10 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•10 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1050815#c13
Updated•10 years ago
|
Target Milestone: --- → mozilla35
Comment 42•10 years ago
|
||
Here's a video recording of this bug:
http://www.youtube.com/watch?v=Wv_CLBapKIU
Comment 43•10 years ago
|
||
(In reply to gnatko from comment #42)
> Here's a video recording of this bug:
>
> http://www.youtube.com/watch?v=Wv_CLBapKIU
It's fixed in FF35.
Comment 44•10 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•10 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.
https://wiki.mozilla.org/Releases
Comment 46•10 years ago
|
||
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).
[1] https://wiki.mozilla.org/RapidRelease/Calendar
[2] https://mail.mozilla.com/home/publiccalendar@mozilla.com/Releases%20Scheduling.html?view=month&date=20150124
You need to log in
before you can comment on or make changes to this bug.
Description
•