791535 - "Password request" dialog / popup windows wastes CPU resources. progress meter spins in status bar

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Toralf Förster]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120907154448

Steps to reproduce:

started Thunderbird and forgot to type in the password


Actual results:

4-core CPU is up to 100%, fan is very noisy


Expected results:

a (milli)sleep in that source code loop to keep my ThinkPad quiet and cool

Comment 1

[Toralf Förster]

maybe a blinking task bar window should be enough for forgetful people like me.

Comment 2

[Wayne Mery (:wsmwk)]

I see this with imap account

Comment 3

[Wayne Mery (:wsmwk)]

steps
1. start thunderbird
2. click on imap account folder where it is set to check for new messages at X interval and does NOT have account password saved.

results:
password prompt comes up
progress meter spins

not 100% reproducible after first occurrence, unless you restart thunderbird

Comment 4

[:aceman]

OK, this is a good reproducible case, I can see it.

Comment 5

[:aceman]

So in case of this statusbar scrollbar it is defined in mail/base/content/mailWindowOverlay.xul id="statusbar-progresspanel". The progress is updated in mail/base/content/mailWindow.js::updateProgress . From what I could see we DO NOT call this function often (only once at beginning and once at finish of the progressbar. It is an "undetermined" mode progress bar so it spins by itself once started. It seems the internal XUL implementation of the progressmeter widget is not very efficient. The implementation is in mozilla/toolkit/content/widgets/progressmeter.xml <binding id="progressmeter-undetermined">. There seems to be a tight loop calling mozRequestAnimationFrame() without any throttling (if the mozRequestAnimationFrame does not have any).

According to http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html this is the intended operation and the application (FF/TB) determines how many frames per second it generates.

So I am not sure what we can do here.

Any anybody check if the progressbar in Firefox is also that CPU heavy?

Comment 6

[:aceman]

Moving to Frontend until we determine if this shouldn't actually go into Toolkit. But Security component was way off.

Comment 7

[Boris Zbarsky [:bzbarsky]]

mozRequestAnimationFrame throttles to run no more than at 60Hz.  That's its whole purpose.

Comment 8

[:aceman]

Is it possible to request even lower framerate? It seems it is quite CPU heavy. The reporter talks 100% of 4-core CPU. But in my testing a tiny progressmeter took 40% of 1 core on a 3Ghz machine. Still a lot.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Is it possible to request even lower framerate?

Not easily, no.  However the callee can of course throttle lower by just checking the call time, which is passed to the method...

Comment 10

[:aceman]

Thanks.
So I modified the binding to only set the spacer properties 3x per second but the CPU usage is not that much down. There must be some other slowness.

Comment 11

[Wayne Mery (:wsmwk)]

Do the profiler links in Bug 562977 reveal anything for you?

Comment 12

[[e-mail]]

(In reply to aceman from comment #5)
> Any anybody check if the progressbar in Firefox is also that CPU heavy?
Depends on the OS; on the Mac it's drawn natively, on Windows there were plans but they didn't come to fruition. It takes up lots of CPU on my Linux system though.

Comment 13

[Boris Zbarsky [:bzbarsky]]

> Do the profiler links in Bug 562977 reveal anything for you?

Mostly painting, no?

Comment 14

[:aceman]

Neil, yes, the original report and also my tests are from Linux. But there is also a noticeable load on Windows XP, like 40% of 1 core of a Core 2 Duo CPU at 2Ghz.

Comment 15

[Wayne Mery (:wsmwk)]

see bug 602126 / Bug 602964 
Is this the same presentation method?

Comment 16

[:aceman]

No idea, but with TB26 I still see the high CPU usage while a progressbar is spinning.

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to [e-mail] from comment #12)
> on Windows there were plans but they didn't come to fruition. It takes up lots of CPU on my Linux
> system though.

is there a bug# for these plans?

Comment 18

[Wayne Mery (:wsmwk)]

matti do you see this on SM?
iirc you run all 3 platforms - what numbers do you get?

Comment 19

[[e-mail]]

(In reply to Wayne Mery from comment #17)
> (In reply to comment #12)
> > on Windows there were plans but they didn't come to fruition.
> 
> is there a bug# for these plans?

Yes, I ended up chasing bug 658829 myself and got the patches landed (and also bug 729649 for good measure), so progress meters don't use XBL animation any more on Windows. (I'm not sure what the name of the animation they use now is called, or whether it uses more or less CPU.)

Comment 20

[Matthias Versen [:Matti]]

I currently can't test on Linux due to my limited time

Comment 21

[:aceman]

Does anybody still see this? Win TB32, in Win XP (as in comment 14) I can't see the high CPU usage. Via DOM Inspector, in TB main window (chrome://messenger/content/messenger.xul) I found <statusbarpanel id="statusbar-progresspanel"> where I set collapsed="true" to uncover the status bar progress meter. Then in <progressmeter id="statusbar-icon"> I set mode="undetermined". The progress bar began spinning without much CPU usage. So the progressbar alone doesn't seem to be the culprit. If we can find the CPU usage in other scenario, maybe something else is contributing to it.

Comment 22

[[e-mail]]

Bug 658829 changed the way undetermined progress meters were painted on Windows from an XBL implementation to a native implementation. Linux still uses the XBL implementation for undetermined progress meters though.

Comment 24

[Wayne Mery (:wsmwk)]

(In reply to [e-mail] from comment #22)
> Bug 658829 changed the way undetermined progress meters were painted on
> Windows from an XBL implementation to a native implementation. Linux still
> uses the XBL implementation for undetermined progress meters though.

The linux side is bug 854093.

Comment 25

[WaltS48 [:walts48]]

I can't reproduce this using Ubuntu Thunderbird 52.3.0 on Ubuntu. My 3-core CPU is at 12%

Comment 27

[Gunter Königsmann]

@WaltS48: A 3 core with Hyperthreading has 6 logical cores. 12% is 100% of one of the logical cores your CPU provides.
@aceman: On MS Windows I don't know. But on Linux if thunderbird is waiting for input from keyboard or the network it still uses a full CPU core.

Comment 28

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #21)
> Does anybody still see this? Win TB32, in Win XP (as in comment 14) I can't
> see the high CPU usage. Via DOM Inspector, in TB main window
> (chrome://messenger/content/messenger.xul) I found <statusbarpanel
> id="statusbar-progresspanel"> where I set collapsed="true" to uncover the
> status bar progress meter. Then in <progressmeter id="statusbar-icon"> I set
> mode="undetermined". The progress bar began spinning without much CPU usage.
> So the progressbar alone doesn't seem to be the culprit. If we can find the
> CPU usage in other scenario, maybe something else is contributing to it.

for linux see Gunter's bug 562977 comment 55

Comment 29

[:aceman]

Progressmeters were replaced with a different implementation (no longer XUL).
Can you please retest on trunk (TB65) ?

Comment 30

[Toralf Förster]

I'd say, this is solved with current version 60.2.1