Closed Bug 1065502 Opened 7 years ago Closed 7 years ago

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

Categories

(Core :: ImageLib, defect)

29 Branch
x86_64
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: sr, Unassigned)

References

Details

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%
Summary: 100% CPU usage of Firefox with an css based image gallery → 100% CPU usage of Firefox with a css based image gallery
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
Flags: needinfo?(sr)
I can reproduce on windows7. The third small image is repainted forever, so high CPU usage.
Probably, This is duplication of Bug 1060200 .
Component: Untriaged → ImageLib
OS: Linux → All
Product: Firefox → Core
setting image.high_quality_downscaling.enabled = false helps.
Blocks: 486918
Status: UNCONFIRMED → NEW
Depends on: 1060200
Ever confirmed: true
(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. :[
(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.
(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.
Blocks: 689623
No longer blocks: 486918
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?
(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
Flags: needinfo?(sr)
(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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
(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.
You need to log in before you can comment on or make changes to this bug.