The default bug view has changed. See this FAQ.

CPU usage spikes because of animated hidden images

VERIFIED FIXED in mozilla2.0b10

Status

()

Toolkit
Add-ons Manager
VERIFIED FIXED
6 years ago
4 years ago

People

(Reporter: KWierso, Assigned: Unfocused)

Tracking

({perf})

Trunk
mozilla2.0b10
All
Windows 7
Points:
---
Bug Flags:
in-testsuite -
in-litmus -

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [softblocker])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
When I open about:addons (and am currently viewing it in the selected tab), I see in task manager that firefox.exe is fairly constantly using ~20% CPU (it drops down to 0% every once in a while, but it holds almost constantly above 15%) for me, using a Core2Duo processor.

Disabling hardware acceleration didn't seem to make a difference, nor did safe mode.

I found that when I deleted the following element via Firebug, CPU usage dropped down to close to 0%:
/page/hbox[2]/box/deck/deck/vbox/hbox/image
(This is the empty <image> tag inside the "alert loading" <hbox>, which is in the "discover-loading" <vbox>, which is in the "discover-view" <deck>, in the "view-port" <deck>, in the "view-port-container" <box>.)

Mossop mentioned needing a profile to help identify what's going on here. I'm not quite sure what I need to do to create that profile, but I'm willing to help out with guidance.
Oh, don't tell me we're still animating hidden images?...
<Mossop> joe: Do we still animate images that aren't visible?
<joe> Mossop: yeah
* Mossop cries
<joe> if we don't we have to keep track of how far along they are in their animation

Probably going to want to block on this. We need to make images that are animated (the loading throbbers) switch to a blank image whenever they are hidden.
blocking2.0: --- → final+
Whiteboard: [good first bug]
Or apparently display: none on an image will stop it animating (where visibility: hidden) will not)

Comment 4

6 years ago
Created attachment 501838 [details]
Example of: Add-on manager high CPU usage problem

High CPU usage (recently, at least on one cpu (I have only 1)), when displaying about:addons (any page, ex: Get add-ons; Extensions...). Using AMD XP 2600.

If I remember correctly problem seemed to have started when 'Bug 611241 - xul:image with a SVG filter won't display on "about:" pages' landed.

This bug landing seemed to have caused other bugs such as:
    Bug 621253 - "Extension"/"Plugins" pane of "Add-ons Manager" is drawn wrongly if zoom level not equal 100% in site specific zoom and disabled extension/plugin existed.
Summary: CPU usage spikes when viewing about:addons → CPU usage spikes because of animated hidden images
I'm experiencing this, too. This also makes addons list scrolling extremely slow and laggy.
(Reporter)

Comment 6

6 years ago
Created attachment 501932 [details] [diff] [review]
would this work?

I have no idea if this would even work.

Something along these lines?
Attachment #501932 - Flags: feedback?(dtownsend)
(Reporter)

Comment 7

6 years ago
Comment on attachment 501932 [details] [diff] [review]
would this work?

Could've sworn I hit the "patch" checkbox the first time around...
Attachment #501932 - Attachment is patch: true
Attachment #501932 - Attachment mime type: application/octet-stream → text/plain
Duplicate of this bug: 623615
Keywords: perf
OS: Windows 7 → All
Hardware: x86 → All
(In reply to comment #5)
> I'm experiencing this, too. This also makes addons list scrolling extremely
> slow and laggy.

That's bug 623615 and as it looks like not caused by the animated images.
Comment on attachment 501932 [details] [diff] [review]
would this work?

It's along the right lines but I imagine you'll then still see the CPU use if the discovery pane is visible but the loading message hidden.

You can I think simplify it by doing something like

#discover-view:not(selectedIndex="<whatever this is>") .loading {
  display: none
}

There is also two other loading throbbers in the UI, do they need the same treatment?
Attachment #501932 - Flags: feedback?(dtownsend) → feedback-
(Reporter)

Comment 11

6 years ago
(In reply to comment #10)
> 
> There is also two other loading throbbers in the UI, do they need the same
> treatment?

Only deleting the discovery view throbber via Firebug helped with CPU usage for me, for whatever reason.

> Henrik Skupin [:whimboo]: Keywords: perfHardware: x86 ⇒ All OS: Windows 7 ⇒ All
Is this affecting non-Windows builds too? If it does, the patch will have to be elsewhere or in all the themes.
No, sorry about that. I have changed it because of the wrongly duped bug.
OS: All → Windows 7
Yeah the patch should go into the extensions.css in content rather than the theme code.
Created attachment 502755 [details] [diff] [review]
Patch v1

I could only see a 3% to 4% CPU hit from this on my machine (and even then, only once every few seconds). But I believe this fixes it. In addition to hiding the discovery pane throbber, I've moved the code that hides the details pane loading message out of themes and into content, and made it hidden rather than just collapsed. AFAIK, every other throbber is already hidden when its not visible.

Since the performance hit on my machine (3-4%) was so little compared to the reporter's (20%), I want to double check this improves things. I'll have Try builds up tomorrow for people to test.
Assignee: nobody → bmcbride
Attachment #501932 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #502755 - Flags: review?(dtownsend)
Whiteboard: [good first bug] → [has patch][waiting on try][needs review Mossop]
Whiteboard: [has patch][waiting on try][needs review Mossop] → [has patch][waiting on try][needs review Mossop][soft blocker]
Attachment #502755 - Flags: review?(dtownsend) → review+
Whiteboard: [has patch][waiting on try][needs review Mossop][soft blocker] → [has patch][waiting on try][soft blocker]
(Reporter)

Comment 15

6 years ago
The w32 tryserver build has no CPU spikes that I can see from a quick testing on my machine.
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bmcbride@mozilla.com-4554a2185bf9/
(In reply to comment #15)
> The w32 tryserver build has no CPU spikes that I can see from a quick testing
> on my machine.

Great - thanks for checking :)
Whiteboard: [has patch][waiting on try][soft blocker] → [has patch][needs landing][soft blocker]
Landed: https://hg.mozilla.org/mozilla-central/rev/2570a56d5786

Would there normally be a litmus test for this sort of thing? Might be useful to have something generic, checking CPU usage doesn't go up unexpectedly.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite-
Flags: in-litmus?
Resolution: --- → FIXED
Whiteboard: [has patch][needs landing][soft blocker] → [soft blocker]
Target Milestone: --- → mozilla2.0b10
Whiteboard: [soft blocker] → [softblocker]

Comment 18

6 years ago
It should have been in content in the first place, and secondly using display:none is always better than visibility:hidden IMHE.
I can't see the spikes anymore. Verfied fixed with Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110112 Firefox/4.0b10pre

I don't think it is worth a Litmus test. We know why it happens, we have solved the problem, and it's noted in the code. Also wouldn't it be safer when even "!important" is specified for the rule?
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus-
Maybe, but those rules are pretty specific - much more specific than anything you'd use to style what they hide (more specific rules win, in CSS). I always try to avoid using !important whenever possible - it seems to do more harm than good, in my experience.
Depends on: 626358

Updated

4 years ago
See Also: → bug 872780
You need to log in before you can comment on or make changes to this bug.