Closed
Bug 1065502
Opened 10 years ago
Closed 10 years ago
100% CPU usage of Firefox with a css based image gallery
Categories
(Core :: Graphics: ImageLib, defect)
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%
Reporter | ||
Updated•10 years ago
|
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)
Comment 2•10 years ago
|
||
I can reproduce on windows7. The third small image is repainted forever, so high CPU usage.
Probably, This is duplication of Bug 1060200 .
Updated•10 years ago
|
Component: Untriaged → ImageLib
OS: Linux → All
Product: Firefox → Core
Comment 3•10 years ago
|
||
setting image.high_quality_downscaling.enabled = false helps.
(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.
Comment 6•10 years ago
|
||
(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.
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?
Reporter | ||
Comment 8•10 years ago
|
||
(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)
Comment 9•10 years ago
|
||
(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: 10 years ago
Resolution: --- → FIXED
Comment 10•10 years ago
|
||
(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.
Description
•