Thunderbird: high CPU usage from progress bars

[Jan]

Binary package hint: mozilla-thunderbird

When sending a simple and short email with Thunderbird via SMTP the CPU is used intensively. This seems not to be necessary. If the sending failed and an corresponding error message dialog appears, the CPU is still being used. When pressing ok to close the error dialog the CPU is fine. This suggests it might be related specifically to the progress bar. Such behavior is especially annoying on a laptop where you can hear the CPU usage because of a starting fan.

[Hilario J. Montoliu (hjmf) (hmontoliu)]

Assigned to Mozilla Team

[Day (day)]

Same pb here. Ubuntu gutsy.

[Jullian Gafar (jullian)]

Still affects Intrepid. Is it ever going to be solved?

jullian@zelda:~$ uname -a
Linux zelda 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:20 UTC 2008 i686 GNU/Linux

[Alexander Sack (asac)]

have you tried to "compact folder ..." for your sent and inbox folders? (right mouse click -> Compact)

[Jullian Gafar (jullian)]

It doesn't change. Still abnormal high processing while sending.

[Alexander Sack (asac)]

maybe its the progress bar that consumes CPU for you? Is there any graphic activity for you when you see this?

[fooooo (pkol.-deactivatedaccount)]

I can confirm this, Ubuntu 8.04, Thunderbird 2.0.0.19.

[Casey (veg9000)]

Same here, with Intrepid. This is with an IMAP account where the sent folder is on the server.

Thunderbird 2.0.0.19+nobinonly-0ubuntu0.8.10.1

[fooooo (pkol.-deactivatedaccount)]

The progress bar moves so I would say there's graphic activity.
How about an option to switch off any progress bars to save cpu/battery?

[Alex Denvir (coldfff)]

We are closing this bug report because it has not been updated for some time. Please reopen it if you have more information to submit, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[Bartek (tschew)]

Reopening because the bug still exists and the source is almost definitely the small progress bar at the lower right-hand corner of the Thunderbird window. To narrow it down I would propose for the people having the problem to report their graphics hardware and the cpu usage from top when the problem occurs.

I see:

thunderbird ~30-50%
Xorg ~20%

on an intel GM45 chipset

I would also rename the bug to reflect that it's not just when sending mail but also when getting new messages. (in short: whenever the progress bar is active)

[Kevin Hunter (hunteke)]

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.3a5pre) Gecko/20100426 Shredder/3.2a1pre

Symptom: any progress bar that appears seems to bring with it a pegged CPU core.

I suggest it's the progress bar code that is polling the CPU. If I send a message, and the send process fails for some reason, the progress bar continues to animate, while a new dialog box appears with a reason for error. Meanwhile, a CPU core is still pegged, even though there is no "real" work being done, just the progress bar animation.

I've noticed the high CPU core usage with *any* progress bar activity, not just the above example. For example, on this latest build, the progress bar in the lower right is attempting to complete while I type this bug report, I presume while it indexes for the first time (first time with /this/ build) my inbox,(>8000 messages). Meanwhile, my CPU graph shows one core in full usage.

Reproducible: Always

Steps to Reproduce:
Here is one method to get a status bar

1. Open Thunderbird.
2. Clear your password
3. Send a message
4. Type in an incorrect password
5. Note the CPU usage when it gives you the SMTP error dialog.

If it matters, I'm using IMAP, but again, I doubt that's the issue. I think it's the scroll bar code.
Actual Results:
When any progress bar is visible, a processor goes berserk.

Expected Results:
When any progress bar is visible, the CPU usage caused by the progress bar should be pert near zero.

These bugs may be relevant, or may turn out to be duplicates. I couldn't quite tell from the descriptions:

https://bugzilla.mozilla.org/show_bug.cgi?id=367431
https://bugzilla.mozilla.org/show_bug.cgi?id=538283
https://bugzilla.mozilla.org/show_bug.cgi?id=543422

[Kevin Hunter (hunteke)]

I've had this problem for ages (3+ years) with Thunderbird. I'm now in triage mode as I've just installed Lucid and I've been tracking down lots of little annoyances.

For the record, Thunderbird 3 has the same issue. I'll point out that it's not *just* the little progress bar, but /any/ progress bar that Thunderbird presents.

$ uname -a
Linux hani 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64 GNU/Linux

$ lspci | grep -i vga
01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce 8400M GS] (rev a1)

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04 LTS
Release: 10.04
Codename: lucid

[Kevin Hunter (hunteke)]

Another reason why I think the issue is specifically with the progress bar code and not, for example, the Gloda code: this issue has been around since at least Thunderbird v1.5. As referenced by Bug 543422, Gloda may *also* be a CPU hog, but I think the this merits it's own bug report.

[Kevin Hunter (hunteke)]

I couldn't find an upstream bug report specifically addressing the progress bars and CPU usage, so I created one:

https://bugzilla.mozilla.org/show_bug.cgi?id=562977

[Kevin Hunter (hunteke)]

Marking as confirmed since it seems a number of people have noticed this issue.

[Vseerror (vseerror)]

Kevin, I don't put any stock in those other bugs.

Are you seeing this mainly with trunk build? ( Trunk builds are currently badly broken.)

Do you see this issue with indexing disabled? (restart after disabling)
If it's only with indexing enabled, can you follow the first two steps at
https://developer.mozilla.org/en/Thunderbird/Gloda_debugging, this should show
you errors in the error console.

[Kevin Hunter (hunteke)]

Index disabled, restarted. Problem persists.

I checked with both the stock Ubuntu Lucid version (v3.0.4) and with the trunk version built 4 days ago (2010 Apr 26).

I recreated the issue as I described above, removing my saved password, sending an email, and then pausing to observe the effects when it asked for my password. High CPU usage until I canceled the "Give me your password" dialog.

[John McPherson (jrm+launchpadbugs)]

$ dpkg -l thunderbird | cat
ii thunderbird 3.0.4+nobinonly-0ubuntu4
$ ps ufax | grep thunderbird
mcp 2166 31.1 18.8 378524 89864 ? Sl 10:40 17:32 \_ /usr/lib/thunderbird-3.0.4/thunderbird-bin
$ strace -p 2166 2>&1 | head -n 20
Process 2166 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 1
gettimeofday({1273620600, 759410}, NULL) = 0
read(19, "\372", 1) = 1
gettimeofday({1273620600, 759608}, NULL) = 0
gettimeofday({1273620600, 759691}, NULL) = 0
write(20, "\372", 1) = 1
gettimeofday({1273620600, 760352}, NULL) = 0
gettimeofday({1273620600, 760412}, NULL) = 0
gettimeofday({1273620600, 760465}, NULL) = 0
futex(0xb75e5588, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xb75e5584, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
gettimeofday({1273620600, 760628}, NULL) = 0
gettimeofday({1273620600, 760763}, NULL) = 0
gettimeofday({1273620600, 760819}, NULL) = 0
gettimeofday({1273620600, 760880}, NULL) = 0
gettimeofday({1273620600, 761036}, NULL) = 0
gettimeofday({1273620600, 761090}, NULL) = 0
gettimeofday({1273620600, 761149}, NULL) = 0
gettimeofday({1273620600, 761212}, NULL) = 0
gettimeofday({1273620600, 761851}, NULL) = 0

It looks like the animation code is doing something very inefficient if it's calling gettimeofday() thousands of times per second.

[Kevin Hunter (hunteke)]

John McPherson just performed a perhaps telling strace of Thunderbird 3.0.4:

https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/109943/comments/15

The telling bit from his comment:

It looks like the animation code is doing something very inefficient if it's calling gettimeofday() thousands of times per second.

From there, here's a similar analysis on May 12th's nightly build:

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.3a5pre) Gecko/20100512 Shredder/3.2a1pre

----------
$ ps -elF | grep thunderbird
0 S kevin 27405 26060 10 80 0 - 99236 poll_s 81960 1 15:06 pts/0 00:01:33 ./thunderbird-bin
0 S kevin 30204 29053 0 80 0 - 1904 pipe_w 916 0 15:20 pts/2 00:00:00 grep --color=always thunderbird

$ time strace -p 27405 2>&1 | head -10000 | grep gettimeofday | wc -l
3803

real 0m2.532s
user 0m0.200s
sys 0m0.440s
----------

That's almost 4,000 requests for gettimeofday() in 10,000 lines retrieved by strace, all in 2.5 seconds. The question is why does some piece of code need to know gettimeofday several thousand times per second?

Note that to recreate this, the same trick of "forgetting" the password when sending a message was used. Also note that indexing is *still* disabled. No Gloda.

[Vseerror (vseerror)]

Peter, Nir
Does this reproduce in your environment?
And even if it doesn't, any thoughts or advice?

Kevin as a practical matter - is it at 100% during the entire time the progress bar is animated?

[Kevin Hunter (hunteke)]

I have 2 cores on my machine. Speaking as an end-user, yes, a single core is pegged at 100% during the entire time the progress bar is active.

[Chris Olin (chris.olin)]

Process 8697 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 1
gettimeofday({1284636702, 520915}, NULL) = 0
read(19, "\372", 1) = 1
gettimeofday({1284636702, 521423}, NULL) = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{"\200\1\2\0\377\0\0\0", 8}, {NULL, 0}, {"", 0}], 3) = 8
poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3, "\1\3_\271\0\0\0\0\376\0\0\0\0\0\0\0\3\0\0\0\0\0\0\0\0\332\273\277\0\0\0\0", 4096) = 32
read(3, 0xb755c058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1284636702, 522628}, NULL) = 0
gettimeofday({1284636702, 522844}, NULL) = 0
gettimeofday({1284636702, 523012}, NULL) = 0
read(3, 0xb755c058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1284636702, 523400}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=37, events=POLLIN}, {fd=24, events=POLLIN}, {fd=18, events=POLLIN}, {fd=71, events=POLLIN}, {fd=41, events=POLLIN}, {fd=19, events=POLLIN}], 13, 0) = 0 (Timeout)
gettimeofday({1284636702, 523785}, NULL) = 0
gettimeofday({1284636702, 523969}, NULL) = 0
read(3, 0xb755c058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1284636702, 524259}, NULL) = 0

[Vseerror (vseerror)]

Kevin, do you still see this problem in version 3.1?
Do one of the bugs in comment 0 really describe your problem well?

[Kevin Hunter (hunteke)]

(In reply to comment #7)
> Kevin, do you still see this problem in version 3.1?

Yes, but not nearly as badly. Now the CPU is about 20%, not 100%. To be clear, I believe from personal experience that animating a simple scroll bar and waiting for user input ought to register at 1% or less CPU utilization.

Performing a similar analysis as above, with Thunderbird waiting for a password (and consequently with a scroll bar going), yields the number of gettimeofday calls to be in the same vicinity (3,500 to 4,000 calls) in 10,000 lines retrieved via strace, and a much more consistent 2,275 POLL events.

Note that I just downloaded and tested Mozilla's copy of 3.1.7 (not my distribution's).

> Do one of the bugs in comment 0 really describe your problem well?

No. I wasn't sure at the time I wrote this bug report, but I became more confident later.

[Vseerror (vseerror)]

with trunk Thunderbird on windows, I see steady cpu usage of 5-30% (avg 9%) when any modal dialog box is up (error, password, etc). Thus, I suspect this is a duplicate.

when NOT logged in to imap account and no dialog box left open, ~2% (new bug?)

when logged in to imap account, and no dialog box left open, ~0%

[Tsu Jan (tsujan2000)]

I encountered this issue with 64-bit Thunderbird 5.0 on Linux (Debian). When the progress bar oscillates between left and right, CPU usage increases so that one of CPU cores is at 100%.

For now, I downgraded to TB 3.1.11, that doesn't show this issue or, at least, not to such an extent.

[Vseerror (vseerror)]

Tsu, Kevin, does CPU go down substantially if you start thunderbird in safe mode? (as it does in Bug 693852)
ref: http://support.mozillamessaging.com/en-US/kb/safe-mode

[Kevin Hunter (hunteke)]

I have just updated the original test with a stock (direct from mozilla.org) copy of Thunderbird, version 7.0.1 (64-bit).

Answer: no. It remains high, between 20% and 50% of a core.

That other bug sounds related, and I would not be surprised if the buggy code is at least partially shared.

[Tsu Jan (tsujan2000)]

Thunderbird 8.0 also suffers from this bug.

[Infinality (infinality)]

This has been happening to me for years, and still happens in 12.0.1. I'm pretty surprised this hasn't gotten more attention. I've had cases where it completely pegs a core- 99 or 100%.

[Tsu Jan (tsujan2000)]

This was the only reason I left TB and used Evolution (in Gnome).

[Kevin Hunter (hunteke)]

As of yesterday, I've gotten fed up with the resource hogishness and stability issues of the default Ubuntu window and desktop managers. I've now installed and configured OpenBox.

Where I was seeing this issue 3 days ago (albeit not as pronounced as once-upon-a-time), I'm now do not notice anything. Other than a 4 or 5 second wait to quit TB, things are right-zippy, with no (known) loss of functionality. I don't know how to confirm, but this certainly leads me to suspect an interaction between Thunderbird and Gnome and Unity. (And I believe KDE too, but it's now 4 years since I last tried KDE ...)

Another data point.

[Vseerror (vseerror)]

(In reply to Kevin Hunter from comment #16)
> As of yesterday, I've gotten fed up with the resource hogishness and
> stability issues of the default Ubuntu window and desktop managers. I've
> now installed and configured OpenBox.

[Kevin Hunter (hunteke)]

Err, to clarify what I think you may be focusing on, the pegged cores were very much attributable to TB (as evidenced by Comments #4 and #8, and my personal observations through ps and htop, etc.), not to the the various Window/Desktop managers.

For purely non-TB reasons, I switched to OpenBox: my computer /really/ bogged down after I installed Ubuntu 12.04 (fresh install -- not upgrade -- if it's of use) on my machine last week. (This is still the same hardware as when I started this bug report.) The speedup of Thunderbird was a happy coincidence, and was not an intentional reason for my switch.

TB definitely still has a performance issue, but one that may be exacerbated by the interaction between the more well-known WMs and DMs.

[Vseerror (vseerror)]

my progress bar was "stuck" running, and no other mail activity going in or out.
http://people.mozilla.com/~bgirard/cleopatra/?1354224788783#report=21c8f8f3b95dacfb84792b2f0e130eb106a28069&jankOnly=true&selection=%255B%2522%28root%29%2522%252C%2522Startup%253A%253AXRE_Main%2522%252C%2522js%253A%253ARunScript%2522%252C%2522gFolderTreeView.OnItemIntPropertyChanged%28%29%2520%2540%2520folderPane.js%253A1837%2522%252C%25220x17f720%2522%255D

[Vseerror (vseerror)]

Here's another profile http://people.mozilla.com/~bgirard/cleopatra/?1354620938776#report=6210e70a7a1f640f9bcbb57e9af8c95997b58917&search=Paint

xref bug 742697

[Vseerror (vseerror)]

there is also activity manager.

<Archaeopteryx> wsm: seem like it starts here: http://mxr.mozilla.org/comm-central/source/mail/components/activity/modules/autosync.js#283
<Archaeopteryx> and onProgressChange gets called too much: http://mxr.mozilla.org/comm-central/source/mail/components/activity/content/activity.xml#485
<wsm> Archaeopteryx: see also https://bugzilla.mozilla.org/show_bug.cgi?id=742697#c14
<firebot> Bug 742697 nor, --, ---, acelists, NEW, SMTP connection progress bar causes high CPU usage
<wsm> how do you know it is called too much?
<Archaeopteryx> just a guess because i see no throtteling code. autsync's comment says it want to prevent event overflow, but it don't see bundling messaes per account at http://mxr.mozilla.org/comm-central/source/mail/components/activity/modules/autosync.js#249 which calls setProgress. you could verify with logging enabled, onDownloadStarted logs in the first lines

[Acelists (acelists)]

That is the question. I have not yet found if there is any throthling or how often these onProgressChange events are fired. I should probably get the time inside the handler and dump it out to see what happens.

Wayne can you come up with good STRs to get a progress bar repeatedly without downloading new messages? So that we can debug the code.

[Vseerror (vseerror)]

(In reply to :aceman from comment #22)
> Wayne can you come up with good STRs to get a progress bar repeatedly
> without downloading new messages? So that we can debug the code.

bug 791535 is a different situation, but is reproducible.
I assume bug 584643 is also reproducible.

collection of related bugs - https://bugzilla.mozilla.org/buglist.cgi?list_id=5125237;short_desc=progress%20activity%20barber%20spin%20spinner%20spinning;field0-0-0=short_desc;type0-0-1=anywordssubstr;field0-0-1=short_desc;resolution=---;query_format=advanced;short_desc_type=anywords;value0-0-1=indicat%20throb;type0-0-0=anywords;value0-0-0=meter%20bar%20pole;product=MailNews%20Core;product=Thunderbird

[Merikes-lists (merikes-lists)]

One more observation: using html:progress takes about 1/2 of the CPU that xul:progressmeter takes when animating.

[Kwang Moo Yi (kwang-m-yi)]

I can confirm that this still happens for me in Debian Sid, thunderbird 52.2.0
The CPU usage goes up quite a bit, actually enough to make the fans kick in.
@zayne.a Can you please provide a bit more detail in how you do that? I tried to googling, without much luck.

[Zayne-a (zayne-a)]

(In reply to kwang.m.yi from comment #48)
> I can confirm that this still happens for me in Debian Sid, thunderbird
> 52.2.0
> The CPU usage goes up quite a bit, actually enough to make the fans kick in.
> @zayne.a Can you please provide a bit more detail in how you do that? I
> tried to googling, without much luck.

View > Toolbars > Status Bar

[Vseerror (vseerror)]

(In reply to David von Oheimb from comment #44)
> ...
> Just set the IMAP Server Name of some account to an unreachable IP address
> like 1.2.3.4 and try getting emails from there.
>
> This bug is apparently very low-level in the Mozilla network layer and has a
> number of related bug reports touched again recently also for FF.

Correct, Firefox gets the same issue. Perhaps a different bug, if the progress meter doesn't spin or your profile is different from the one Merike collected

(In reply to Philip Chee from comment #41)
> WAG: Just a guess. Go to about:config and set the following preferences:
> layers.acceleration.disabled -> true [HWA disabled]
> layers.offmainthreadcomposition.enabled -> false

Note, we've seen a variety of behavior with HWA disabled or enabled. For example, in bug 1267662 HWA disabled improved performance on a Mac

[Vseerror (vseerror)]

Merike, on what OS did you profile?

Note, from bug 781535 comment 24
(In reply to <email address hidden> 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 - Indeterminate progress bar takes entire CPU - in Widget: Gtk

[Merikes-lists (merikes-lists)]

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #51)
> Merike, on what OS did you profile?

Linux.

[Wls220spring (wls220spring)]

I can't reproduce this using the Ubuntu Thunderbird 52.3.0 on Ubuntu 16.04

[PeterPall (peterpall)]

52.6.0 (64-bit) on Ubuntu 18.04. On both gnome on Xorg and gnome on Wayland the progress bar uses 100% of one of my CPUs.
I know that if there is no other task a modern CPU tends to be in sleep mode most of the time (which makes the only task automatically reach 100%). But the progress bar also drains my battery in ca. 40 minutes and makes the CPU fan go haywire => it seems to be hideously inefficient.

[PeterPall (peterpall)]

@WaltS48: I guess I found out why this wasn't reproducible: There are 2 progress bars:
 * the one that is shown if the percentage of progress is known and
 * the one that is shown to indicate that an activity of unknown duration is in progress.
Only the latter one uses 100% of one CPU.

The drawback is: As soon as the network connection drops as you go mobile thunderbird's next attempt to connect to a server is likely to trigger the "activity of unknown duration" type progressbar - and to rapidly drain the accumulator if the mobile device.

Perhaps the activity indicator that has the problem should be better referenced to as "throbber" as a 2nd thought....

[PeterPall (peterpall)]

Thunderbird 60.7.0 still shows this problem.

[Vseerror (vseerror)]

What hope do we have to get away from indeterminate xul:progressmeter for linux (ref comment 47) ?
... for all our dialogs. Unsure if same issue exists anywhere in calendar-land (see "see also" links)

[Mkmelin+mozilla (mkmelin+mozilla)]

xul:progressmeter was converted to html:progress. But looks like it's still reproducible at least on linux.
In scratchpad or console, do

document.getElementById("tabmail-container").appendChild(document.createElementNS("http://www.w3.org/1999/xhtml", "progress"));

... and check CPU usage. For me it goes to around 20% and stays there.

Can also reproduce on Firefox nightly. There in the Developer Tools | Console

document.getElementById("urlbar").appendChild(document.createElementNS("http://www.w3.org/1999/xhtml", "progress"));

The only difference is that there it jumps from listing Firefox to "GPU process" and back. It's still Firefox causing it.

[1-geoff (1-geoff)]

There's only a few which are indeterminate and they're important for providing feedback to the user that something is happening. I think the best solution, if any, is to chase the toolkit people to fix their widget. FWIW I've not had a problem with this thing for years but it probably does use more CPU than necessary, about 6% of a CPU for me.

[Vseerror (vseerror)]

Thanks for the info.

To reemphasize the big problems: a) even at modest amounts of CPU, it sucks battery life, b) at modest amounts (above 5-10%?, I forget the range) it impacts responsivesness when getting new mail, c) to make it worse we have (or at least have had) situations where the progress meter lingers, and even sometimes never goes away due to other brokenness so the CPU usage can be continuous.

(In reply to Geoff Lankow (:darktrojan) from comment #58)
> ... I think the best solution, if any, is to chase the toolkit people to fix their widget.

So far after 10 years in bug 854093 that hasn't worked out so well for linux. (or do we need something else?) Does someone know stransky or do we have some other friend?

On the windows side this required aceman and our friend Neil in bug 658829 (ref bug 791535 comment 19). But even there we still might have an edge case per bug 658829 comment 97.

[nh2 (nh2)]

Thunderbird 68.2.1 on Linux, I can confirm that this issue still exists, with createElementNS() as given above, and the SMTP sending progress bar from bug 742697, and the IMAP loading progress bar in the status bar when switching between folders.

15-20% CPU usage.

[nh2 (nh2)]

How can you match the generated <html:progress> tag with userChrome.css ?

I'd like to style it differently to check how the performance behaves, or hide it, but I don't know how to match it, only its parent `#statusbar-progresspanel`.

[nh2 (nh2)]

**Workaround:**

I found that disabling the indeterminate progress progress bar is not enough; the spinning throbber in the tab is also responsible for CPU usage.

I'm using the below in my Thunderbird profile folder's `chrome/userChrome.css` to disable both, resulting in the 15-20% CPU usage disappearing:

    @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

    /* nh2: Progress bar CPU usage fix. */
    /* For some stupid reason we can't match the html:progress that's the first child of this container.
       See https://bugzilla.mozilla.org/show_bug.cgi?id=562977#c61
       So we can't style the progress bar so that it does doesn't get shown only when
       indeterminate (which takes the most CPU), or style it to render faster.
       So for now we hide the entire parent container, thus getting rid of the progress bar entirely.
    */
    #statusbar-progresspanel {
      display: none;
    }

    /* nh2: Tab throbber animations also take a lot of CPU; hide them.
       Unfortunately I didn't find a way to replace them by a static image.
    */
    .tab-throbber[busy] {
      display: none !important;
    }
    .tab-throbber[progress] {
      display: none !important;
    }

[PeterPall (peterpall)]

This user chrome is a real battery saver! Thanks! ...and the throbber in the mouse pointer still tells me if thunderbird is busy.
---
If I understand this right we now have 2 things that are rendered in the same thread and that use 100% of one CPU (indicated as 50% of the CPU power of a 2-CPU-System, 20% of the CPU power of a 5-cpu-system and 12,5% of the CPU power of an 8-cpu one) if they get the chance of doing so. ...or was the progress meter a Red Herring and it was only the throbber all along?

100% of one CPU normally doesn't indicate that something is amiss: The CPU could be asleep 99% of the time and be busy 1% of the remaining time. But the battery drain throbber+progress meter and generate seems to indicate that the CPU won't sleep while there is indeterminate progress...

[Richard Marti (richard-marti)]

Gunter, you could only apply the rule for #statusbar-progresspanel and check how the CPU usage is with only the throbber spinning.

[nh2 (nh2)]

I have already tested that.

* Only throbber: ~15-20% CPU usage
* Only progress bar: ~15-20% CPU usage
* Both throbber and progress bar: ~15-20% CPU usage
* Both disabled: no CPU usage

@Gunter: I measured CPU usage on Linux with `htop`, where the percentage is always relative to 1 core. 15% means 15% of 1 core. Using full 2 cores would show up as 200%.

> 100% of one CPU normally doesn't indicate that something is amiss: The CPU could be asleep 99% of the time and be busy 1% of the remaining time.

I don't understand this sentence. If the CPU is asleep 99% of the time, CPU usage in `htop` should show up as roughly 1%, not 100%.

[Richard Marti (richard-marti)]

(In reply to Niklas Hambüchen from comment #65)
> I have already tested that.
>
> * Only throbber: ~15-20% CPU usage
> * Only progress bar: ~15-20% CPU usage
> * Both throbber and progress bar: ~15-20% CPU usage
> * Both disabled: no CPU usage

Strange that both together use the same CPU like when only one is active.

Please could you try
```
.tab-throbber[busy] {
  list-style-image: none !important;
}
```
Then I can see if the animated PNG is the cause of the CPU usage.

[nh2 (nh2)]

Yes, `list-style-image: none !important;` also fixes it.

> Strange that both together use the same CPU like when only one is active.

I don't find that strange: Using either progress bar or animated PNG throbber, the screen now has to be drawn at many frames per second. Once you have to redraw, redrawing a bit more doesn't make a big difference.

Separetely: Also useful to know for posterity, the upgrade from Thunderbird 60 to 68 made the indeterminate progress bar a lot more jumpy (it looks like around 10 FPS while the original was much smoother) - but to my surprise that increased jumpiness still didn't reduce CPU usage a lot.

[Vseerror (vseerror)]

Richard, given the most recent bug comments, is a Thunderbird solution possible without addressing bug 854093?

[Nl0 (nl0)]

I really wonder why even after 11+ years this is still not fixed and
reporters like me have been bugged multiple times with needless Needinfo requests?!?

As I wrote several times over several years at several places in this bug tracker:
The problem is easily reproducible with any TB version (meanwhile including 78.4.2.).

Again: just enter an IP address such as 1.2.3.4 as the server name/address.
Then try fetching emails. Until this timeouts,
the progress bar moves forth and back with significant CPU load (10% of one core on my current Linux machine).

[Richard Marti (richard-marti)]

In TB 78 we use now the HTML progressmeter. I hope this helps a bit.
I tried the FX approach with using a SVG as throbber but I see on my system no difference to the PNG throbber with 2% CPU.

For the throbber I could create a patch.

[Nl0 (nl0)]

> In TB 78 we use now the HTML progressmeter. I hope this helps a bit.

Your hope is not fulfilled.
I've just tried TB 68 in comparison with Tb 78 - and got the same 10% CPU load on both.
Again - why don't you IT professionals try out such things yourself?!?

[Richard Marti (richard-marti)]

I'm a voluntary contributor and don't need such comments. It's also not very helpful when I see only 1% difference when I test it.

[Nl0 (nl0)]

One actually does not need to be an IT professional to see that for the given issue there is no improvement with FB 78.

[Richard Marti (richard-marti)]

For the throbber I filed bug 1695950.

[Richard Marti (richard-marti)]

Created attachment 9223784
562977-progressmeter-statusbar.patch

This approach uses our colours to paint the progressmeter to also better fit with our themes. Or do you propose a different colour than --primary?

For the indeterminate state I used the approach FX is using on the download panel.

I hope this helps with the CPU usage. I can't say if it's better as for me it is still the same low value.

[W-alessandro (w-alessandro)]

Comment on attachment 9223784
562977-progressmeter-statusbar.patch

Review of attachment 9223784:
-----------------------------------------------------------------

I tested this on my slow mac and the CPU usage spikes up to 60%, with or without this patch.
Nonetheless, the UI changes to the progress bar are welcome as it brings consistency to the interface.

I'm not sure I like the current style of the progress bar.
The height is a bit too tall and the border + bg color + animation + progress color makes this little widget look a bit busy and over styled.
What do you think about:
- 4px height
- 2px border radius
- no border color

I'll see if I have any capacity later this week to investigate this and see if I can find how to prevent the spike in CPU usage.

[Richard Marti (richard-marti)]

Created attachment 9225034
562977-progressmeter-statusbar.patch

This patch implements your wishes.

I hope you have some cycles to check where the high CPU load comes from.

[W-alessandro (w-alessandro)]

Comment on attachment 9225034
562977-progressmeter-statusbar.patch

Review of attachment 9225034:
-----------------------------------------------------------------

Looks good, thanks.
Let's leave this open so I can later take it and investigate the performance issue.

::: mail/themes/shared/mail/folderProps.css
@@ +25,1 @@
> overflow: hidden;

little nit: this could benefit from a `vertical-align: middle` in the folder props dialog, because the default value from toolkit is `-0.2em`, for whatever reason.

[Richard Marti (richard-marti)]

Created attachment 9225128
folderprops-align.png

(In reply to Alessandro Castellani [:aleca] from comment #78)
>
> little nit: this could benefit from a `vertical-align: middle` in the folder
> props dialog, because the default value from toolkit is `-0.2em`, for
> whatever reason.

I leaved it like it is. With `vertical-align: middle` it is too low, see screenshot, at least with normal scaling.

[Pulsebot (pulsebot)]

Pushed by <email address hidden>:
https://hg.mozilla.org/comm-central/rev/fb607a0fb095
Make the progressmeter use the theme colors. r=aleca

[Vseerror (vseerror)]

(In reply to Alessandro Castellani [:aleca] from comment #78)
> ...
> Let's leave this open so I can later take it and investigate the performance issue.

Is there a solution? Or should this be delegated to someone else?

[W-alessandro (w-alessandro)]

This slipped between other bugs, thanks for the ping.

I'm not sure there's anything else to do here as I can't reproduce this issue anymore.
Tested on 91.5.1 and on my mac the usage remains around 5% without spiking anymore.
Also, if I'm not wrong, this is not a XUL element anymore but it's not a standard HTML progressbar.

Can anyone else still reproduce it?

[Richard Marti (richard-marti)]

I'll close the bug as we can't reproduce it.

[Vseerror (vseerror)]

(In reply to Richard Marti (:Paenglab) from comment #83)
> I'll close the bug as we can't reproduce it.

Rather than Wontfix, it seems to me we should use WORKSFORME (for not reproducible using the STR) or Fixed via comment 80.

[Vseerror-i (vseerror-i)]

This has a checked in patch, so I think the resolution should reflect the effort as fixed, to the best extent possible at the time.