User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140428193838 Steps to reproduce: Used background-size:100% 100% with an image 248x257 pixels Note: image height is prime number (speculation) See: http://kurdologie.strictly-html.de/flickerbug/ on menu buttons above (I will not change that page) Actual results: Constant flickering of the background image, consuming considerable CPU load. Expected results: No flickering and CPU low after rendering the page

I can confirm the flickering in the testpage User agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 Build identifier: 20140428215857 flickering stops, when I once look at the unzoomed background-image via View->Page Info->Media or if background-size is set to a fixed (pixel-based) size.

Please somebody confirm the following. When image.high_quality_downscaling.enabled = false in about:config, the problem is fixed?

I can confirm this bug, in my linux nightly. Comment 2's suggested pref-tweak does indeed fix it.

Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 32.0a1 (2014-05-19)

mozregression traces this to this range: { Last good revision: dac5700acf8b (2012-10-17) First bad revision: cb573b9307e5 (2012-10-18) Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dac5700acf8b&tochange=cb573b9307e5 } ...which unsurprisingly, includes a patch (for bug 795940) to enable the downscaling pref mentioned in comment 2: http://hg.mozilla.org/mozilla-central/rev/60f8112284ec

(shamelessly stealing Alice0775's zipped reduced testcase from bug 1013536, since [on my system] it works as a testcase for this bug. I'm attaching the testcase files individually so that you don't have to unzip to test it.)

Note: With "testcase 1", and with paint flashing enabled, I *only* see flashing when both images are scrolled into view. If I make the window small and scroll such that only one of the images is visible, then the flashing stops. (I'm guessing this is due to a quirk of how high-quality downscaling behaves; maybe it caches the last downscaled rendering, or something like that.)

Yeah, it only has one downscaled image at a time, so if a different size then what is currently stored in the downscaler is painted it will get rid of the "old" one and downscale to another size. If two copies of the same image but with different sizes are visible it will go back and forth between them endlessly. There are several bugs suffering from this problem.

Seth probably knows the appropriate dependency to add for this bug.

Bug 977459 should fix this.

Initially commented on bug 977459 but realized after posting that this may be the better bug to comment on. Sorry for the double post. Since there is no ETA yet on the DrawAPI refactoring that bug 977459 depends on, is there a possibility to get an intermediate fix in in the image handling so at the very least HQ downscaling can be enabled without penalty? I think that simply allocating independent buffers for downscaled images (since it only happens when the images are of the same src) should work? i.e.: treat al downscaled images as-if they are unique (of a unique source). It would slightly increase memory use, but at least won't peg the CPU anymore.

(In reply to Mark Straver from comment #12) > Since there is no ETA yet on the DrawAPI refactoring that bug 977459 depends > on As I mentioned in bug 977459, that refactoring has already landed and is marked resolved. I've decided to split bug 977459 into multiple smaller bugs. This particular issue will be handled by bug 1060200. I'm changing dependencies accordingly.

This was fixed by bug 1060200. I just checked, and I don't see this issue anymore on current Nightly.