1065502 - 100% CPU usage of Firefox with a css based image gallery

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Stefan Ruppert]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
Build ID: 20140428194215

Steps to reproduce:

Open page http://myarm.com/inuse.html#inuse-screenshots

You will see a gallery of images with 7 small images and one big image.

For example clicking on the third small image will show up this image in the large area and the CPU usage will increase up to 100%.

After reloading the page or clicking another tab (e.g. 'Customers') and clicking again the 'Screenshot' tab the CPU usage is normal again.

Tested with Firefox v29, v30, v31 and v32.


Actual results:

After clicking on the third small image the CPU usage increase up to 100%. Sometimes the large image seems to flicker.

If the image is smaller than the large area all is fine. The CSS for the large image area spans the image to the complete area by using 'width: 100%' and 'height: 100%' CSS attributes.



Expected results:

The CPU usage should not be at 100%

Comment 1

[Loic]

WFM on Win 7.

Did you test with a clean profile?
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 2

[Alice0775 White]

I can reproduce on windows7. The third small image is repainted forever, so high CPU usage.
Probably, This is duplication of Bug 1060200 .

Comment 3

[Alice0775 White]

setting image.high_quality_downscaling.enabled = false helps.

Comment 4

[Loic]

(In reply to Alice0775 White from comment #3)
> setting image.high_quality_downscaling.enabled = false helps.

Ah, another bug with HQ downscaling. I dunno why this pref has been enabled, it's full of bugs. :[

Comment 5

[Elbart]

(In reply to Loic from comment #4)
> Ah, another bug with HQ downscaling. I dunno why this pref has been enabled,
> it's full of bugs. :[
No proper scaling in 2014 would be laughable.

And, more importantly, it's probably not scaling that's broken, but image-visibility.

Range:
Last good revision: c233837cce08 (2013-02-25)
First bad revision: 73f0c5b00572 (2013-02-26)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c233837cce08&tochange=73f0c5b00572

Most likely bug 689623, as setting layout.imagevisibility.enabled to false is also helping.

Comment 6

[Alice0775 White]

(In reply to Elbart from comment #5)
> (In reply to Loic from comment #4)
> > Ah, another bug with HQ downscaling. I dunno why this pref has been enabled,
> > it's full of bugs. :[
> No proper scaling in 2014 would be laughable.
> 
> And, more importantly, it's probably not scaling that's broken, but
> image-visibility.
> 
> Range:
> Last good revision: c233837cce08 (2013-02-25)
> First bad revision: 73f0c5b00572 (2013-02-26)
> Pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=c233837cce08&tochange=73f0c5b00572
> 
> Most likely bug 689623, as setting layout.imagevisibility.enabled to false
> is also helping.

Okay, I change dependency.

Comment 7

[Elbart]

Trying an inbound-build with bug 1060200 landed, the CPU-load is normal after clicking a thumbnail, and all of the thumbnails are hq-scaled.
Can somebody confirm this?

Comment 8

[Stefan Ruppert]

(In reply to Elbart from comment #7)
> Trying an inbound-build with bug 1060200 landed, the CPU-load is normal
> after clicking a thumbnail, and all of the thumbnails are hq-scaled.
> Can somebody confirm this?

Downloaded nightly build inbound version: "Mozilla Firefox 35.0a1" and CPU-load is normal! Thanks!

Which release of Firefox will get this fix?

Stefan

Comment 9

[Seth Fowler [:seth] [:s2h]]

(In reply to Stefan Ruppert from comment #8)
> Which release of Firefox will get this fix?

Expect it in Firefox 35.

Thanks for verifying this is fixed, everyone! I'm resolving this bug.

Comment 10

[Timothy Nikkel (:tnikkel)]

(In reply to Elbart from comment #5)
> Most likely bug 689623, as setting layout.imagevisibility.enabled to false
> is also helping.

I'm guessing the reason bug 689623 affects this is that there is a non-visible copy of the image somewhere on the page, so when we remove the lock from this copy of the image the image is left with it's lock count being exactly 1. And the lock count being 1 of an image was the requirement for an image to be HQ downscaled (until bug 1060200 landed) exactly because of bugs like this, but as this bug proves, it is not enough to prevent this type of bug.