Open Bug 1730423 Opened 3 years ago Updated 1 year ago

High CPU usage due to the mouse hover e-mail message list highlight feature with webrender enabled (slow XUL tree scrolling performance)

Categories

(Thunderbird :: Folder and Message Lists, defect)

Thunderbird 91
defect

Tracking

(thunderbird113 affected)

Tracking Status
thunderbird113 --- affected

People

(Reporter: adm, Unassigned, NeedInfo)

References

(Depends on 1 open bug, )

Details

(Keywords: perf, stalled, Whiteboard: [workaround: comment 13])

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

My Linux Arch/Manjaro TB package was just upgraded:
78.14.0-0.1 -> 91.1.0-0.1
and immediately i have noticed the new feature/issue:
in the unified Inbox i am moving mouse up/down quickly through the list of e-mails and i can see that the line the mouse is on is highlighted with delay, meaning that this highlight action may be not optimized/badly made or CPU heavy.
And i think that my XFCE tray CPU usage meter is showing that the CPU usage rise when i move the mouse through the list of e-mails.
I can confirm this by running "htop" in terminal, F4, type "thund", enter now move cursor in thunderbird and i can see that the CPU usage of the /usr/lib/thunderbird/thunderbird jumps from 2% of the CPU core to the 30-60% of the CPU core.

Expected results:

Feature optimized to have nearly no performance impact or removed.

this stupid system does not allow me to adjust what i have just posted (possibly admin or creators wants to waste the time of the developers)

unified Inbox -> TB/View/Folders/Unified
but the issue happen also in normal folders.

Component: Untriaged → Folder and Message Lists
Keywords: perf
OS: Unspecified → Linux

I am not willing to publish it here for privacy reason. If anyone is able to fix the issue and is unable to reproduce it, then let me know the private contact and i will try to provide the detail.

(In reply to 794632548 from comment #0)

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

My Linux Arch/Manjaro TB package was just upgraded:
78.14.0-0.1 -> 91.1.0-0.1
and immediately i have noticed the new feature/issue:
in the unified Inbox i am moving mouse up/down quickly through the list of e-mails and i can see that the line the mouse is on is highlighted with delay, meaning that this highlight action may be not optimized/badly made or CPU heavy.
And i think that my XFCE tray CPU usage meter is showing that the CPU usage rise when i move the mouse through the list of e-mails.

arnauld, can you reproduce this?

Flags: needinfo?(arnauld)

(In reply to Wayne Mery (:wsmwk) from comment #4)

arnauld, can you reproduce this?

Hello,

Laptop hp OS: Manjaro 21.1.2 Pahvo / Kernel: x86_64 Linux 4.19.205-1-MANJARO
CPU: Intel Core i3 M 330 @ 4x 2.133GHz GPU: NVA8 RAM: 2396MiB / 3870MiB
TB: 91.1.0 (64-bit)

in the unified Inbox i am moving mouse up/down quickly through the list of e-mails and i can see that the line the mouse is on is > highlighted with delay, meaning that this highlight action may be not optimized/badly made or CPU heavy.

For me I have no problems, I move the mouse up/down/highlighted quickly with no delay at all.

And i think that my XFCE tray CPU usage meter is showing that the CPU usage rise when i move the mouse through the list of e-mails.

When I move the mouse quickly through the list of e-mails my TB CPU usage is between 1 to 30%.

So everything is working fine for me, no problems at all.

I wanted to post a proof video what i am doing and the issue i am seeing, here please

Related concerns found in Archlinux forum and Reddit r/Thunderbird.

ya I'm seeing this also. Thunderbird hangs for a few seconds when selecting an email and scrolling down the body. It happens initially then seems to be ok. It's almost reproducible... just click on another email, click back to the original, and try scrolling down. Do this until it occurs again. This also triggers an error:

IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: PClientManager::Msg_ExpectFutureClientSource Processing error: message was deserialized, but the handler returned false (indicating failure)

Other errors include:

ERROR style::stylesheets::rule_parser] Saw @import rule, but no way to trigger the load

(xfce4-panel:659): xfce4-panel-CRITICAL **: 18:26:19.276: panel-window.c:2391 (panel_window_active_window_geometry_changed): expression 'WNCK_IS_WINDOW (active_window)' failed.
JavaScript error: resource:///modules/AddrBookCard.jsm, line 166: NS_ERROR_NOT_AVAILABLE: PreferDisplayName: undefined - not a boolean

The later actually causes my display to go black for a few seconds!!! Could be unrelated, but only happens when launching thunderbird. Effects v91.1.0 and up.

This one also:

JavaScript error: resource://gre/modules/ActivityManager.jsm, line 129: NS_ERROR_NOT_AVAILABLE:

This is on Arch (XFCE).

I have the same problem and I'm running Thunderbird on Windows 7 x64. Previous major version (78.X) worked without a problem.

When moving the mouse cursor over the emails in the message list pane, the highlight effect considerably lags behind the cursor (similar to the video posted by the reporter). Checking the Task Manager shows two Thunderbird processes jump to a combined CPU usage of 60-80 % (the first process takes 50-70 % and the second between 10-20 %).

Computer: CPU: Intel Q6600 @ 2.4 GHz / 8 GB RAM / GPU: Radeon HD 5850 1 GB VRAM / Windows 7 x64
TB: 91.1.1 (32-bit)

Changing severity to S3 because of modest performance

Severity: -- → S3
Depends on: 1697999
Summary: High CPU usage due to the mouse hover e-mail list highlight feature → High CPU usage due to the mouse hover e-mail message list highlight feature

I see at least two reports confirming this in Mozilla Thunderbird support, including Windows, Mac and GNU/Linux - and I have the same problem (TB 91.1.2 on Windows 10).

This makes Thunderbird slow to the point it can't be used normally.

A possible workaround was mentioned here :
https://support.mozilla.org/en-US/questions/1347196#answer-1435915

If I go to preferences --> config editor and search for the entries:

gfx.webrender.all
gfx.webrender.force-disabled

Switch the first one to false (it was already switched to false) and the second one to true (I switched this one manually)
everything works smooths and no cpu usage jumps happen.

I suggest raising importance/severity. People upgrading seldom backup their Thunderbird profile and when this happens, all the usual "Thunderbird is slow" are being tried without a solution, bringing a user closer to stop using Thunderbird and go to other options.

A few references to people reporting this problem :

The workaround worked for me (GNU/Linux).

Same problem Thunderbird 91.1.2 on macOS 11.6, i7, 32GB.
Just moving the mouse over folder entries, without clicking, was so slow it was unusable.
Workaround worked for me as well.

I was the author of the previously mentioned thread in the ArchLinux forum (comment #7 and #14).

Just dropping by to confirm: The workaround quoted in comment #13 works for me.
After changing the two values, Thunderbird's idle CPU usage drops below 1 % according to htop and sits (close) to 0 % frequently. When hovering over e-mails or folders, no significant increase of CPU load can be observed.

On my 4.2GHz i7 running Fedora 34 I regularly (20-30 times in an 8-hour day) have the UI freeze until GNOME's "application not responding, wait or kill" message appears. I'd respectfully suggest S3 is much too low.

thunderbird/thunderbird-wayland 91.1.0-1.fc34.x86_64 (installed from RPM).

The workaround seems to 'fix' Thunderbird 91.1.0 Fedora 34 (thunderbird-91.1.0-1.fc34.x86_64). I ran the performance profiler before the change with and without add-ons enabled and saved the respective json files along with screenshots from the 3 profiler tabs if anyone wants/needs them.

Confirming based on multiple reports. But the resolution likely must come from the removal of xul in bug 1724841 (which won't happen until next year), or in combination of a graphic fix by firefox core developers (based on a performance profile, as mentioned in bug 1697999).

Does anyone have a workaround that has webrender enabled but some sub functionality disabled?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: High CPU usage due to the mouse hover e-mail message list highlight feature → High CPU usage due to the mouse hover e-mail message list highlight feature with webrender enabled

Reporting on additional unwanted behavior which doesn't get resolved using the workaround mentioned in comment #13.

The same high lag and slowness is noticed when scrolling through the e-mail/message list pane, either using the mouse scroll wheel or the scroll bar.

Running on Windows 7 x64, TB version: 91.2.0(32-bit).

(In reply to cdcwvbjibv from comment #21)

Reporting on additional unwanted behavior which doesn't get resolved using the workaround mentioned in comment #13.

The same high lag and slowness is noticed when scrolling through the e-mail/message list pane, either using the mouse scroll wheel or the scroll bar.

Running on Windows 7 x64, TB version: 91.2.0(32-bit).

Correction.

Running on Windows 7 x64, TB version: 91.2.0 (64-bit).

Depends on: tb-deforestation
Keywords: stalled
Whiteboard: [workaround: comment 13]

Downstream Ubuntu bug: https://launchpad.net/bugs/1959747

I confirm this on the most recent distributions of Arch Linux and Thunderbird.

The suggested fix works to solve the sluggishness.

Running on Fedora-35, with KDE, Radeon RX6600, and Thunderbird 91.7.0, I can confirm that the above suggested fix does NOT solve the high-cpu usage problem. Even after setting "gfx.webrender.force-disabled" to "true" (and confirming "gfx.webrender.all" to be "false"), moving the mouse over either the message list or the folder list results in high cpu usage and much sluggishness; I can easily move the mouse more than fast enough to have the "hover highlight" not be able to keep up.

Same here on Fedora 36, Thunderbird 91.8.0 (64 bit).

More interesting, is can anyone reproduce this when using version 102? from https://www.thunderbird.net/

Webrender is much improved in version 102 for Windows. Perhaps it is also better for Linux.

Flags: needinfo?(droidbittin)

I can reproduce this on Fedora 36 with Thunderbird 102.2.0 on Wayland.
Setting gfx.webrender.all false and gfx.webrender.force-disabled true doesn't reduce CPU usage for me.

A capture documenting this bug with Thunderbird 102.2 on Linux (Fedora 36, Wayland): https://share.firefox.dev/3wAF2hd
Between 1.5s and 4.5s the mouse pointer is moving over the message list.

Debian 11 just upgraded to Thunderbird 102, which has removed the possibility of disabling webrender, rendering Thunderbird on my computer basically unusable. I was forced to downgrade to version 91.

high CPU usage and around 100ms delay on hover animations when moving mouse over emails and menu items.

System is Debian 11.5, Xfce, AMD Ryzen 4750u with integrated graphics in a Thinkpad T14 AMD Gen 1.

which has removed the possibility of disabling webrender

I assume you already tried the newest graphics drivers.

Why would you want to *completely * disable WebRender? Do hardware AND software WebRender crash for you? You can set gfx.webrender.software to true to disable hardware WebRender and enable software WebRender instead. Please try this instead of using an e-mail client with security vulnerabities (since Thunderbird 91 won't receive any further security update we have to assume that Thunderbird 91 is insecure now).

(In reply to Sören Hentzschel from comment #31)

which has removed the possibility of disabling webrender

I assume you already tried the newest graphics drivers.

Why would you want to *completely * disable WebRender? Do hardware AND software WebRender crash for you? You can set gfx.webrender.software to true to disable hardware WebRender and enable software WebRender instead. Please try this instead of using an e-mail client with security vulnerabities (since Thunderbird 91 won't receive any further security update we have to assume that Thunderbird 91 is insecure now).

Perhaps it's not actually realted to webrender, I just assumed that because disabling it solved problems in the past. I use the drivers built into the kernel and I am on a 5.18 kernel. There were no differences in performance with software mode, so it could very well not be related to webrender.

It seems that the high CPU usage and slow UI update is worse when the message list is big and the window is big. If I make it that only 10 rows are visible, it seems to be faster. Here is a profile of the mouse moving around a large message list. https://share.firefox.dev/3y3PfU2

I am seeing the exactly same behavior as Adi on Ubuntu 22.04. I manually upgraded to Thunderbird 102 via the mozilla ppa and I am seeing the same high CPU usage on mouse hover and delayed animations, which made the UI almost unusable for me. My first guess was also the WebRender as I had to disable it for Thunderbird 91. However, I do use Firefox 105 without problems. So maybe it is indeed a different issue.

(In reply to Adi from comment #32)

...
It seems that the high CPU usage and slow UI update is worse when the message list is big and the window is big. If I make it that only 10 rows are visible, it seems to be faster. Here is a profile of the mouse moving around a large message list. https://share.firefox.dev/3y3PfU2

According to experts in matrix chat, "https://share.firefox.dev/3UR69z3 (profile from comment 32, we don't have symbols so I collapsed libxul.so). The profile from comment 29 has symbols, so we can see a bit more what happens: https://share.firefox.dev/3y7gOMy Both profiles show too much time drawing SVG images (and too many Image Paint markers for these images). The profile from comment 32 additionally has an insane amount of time spent doing an SQL query from getCardFromProperty. From looking at the profiles, it's not obvious to me if the SVG images are repeated too many times because of a Thunderbird bug, or if they are painted too many times due to a graphics bug."

Flags: needinfo?(droidbittin)

It seems that the high CPU usage and slow UI update is worse when the message list is big and the window is big. If I make it that only 10 rows are visible, it seems to be faster. Here is a profile of the mouse moving around a large message list.

I can confirm exactly this! Working on a 2 screen setup:

main screen: 3840x2160
secondary: 2560x1440

Arch Linux, Swaywm. Usually all clients (windows) are maximized.

Thunderbird on the main screen has a very bad performance. It is everything else than fun to work with.. :(
As soon as i move thunderbird to the second screen (or switch to floating an make it smaller) the performance increases significantly.

It seems like only the email list is affected. Folder tree for example is fine..

It's been a long time now and kinda renders thunderbird more or less unusable for me. Is there anything I can do to get this fixed? Happy to provide more information if needed!

Thanks for effort :)

Perhaps it's not actually realted to webrender, I just assumed that because disabling it solved problems in the past.
+1. Webrender on/off does not matter here at all.

Maybe also worth mentioning:
I am on a 10th gen Intel GPU with 6.0.9-zen1-1-zen kernel

Boring workaround:

Switch to classic view and move the reading pane up until the message list is snappy enough

Good development progress is being made on "deforestation". Beta should be available on a month or two. And then released in July with version 115.

Flags: needinfo?(arnauld)
OS: Linux → All
Hardware: Unspecified → All
Summary: High CPU usage due to the mouse hover e-mail message list highlight feature with webrender enabled → High CPU usage due to the mouse hover e-mail message list highlight feature with webrender enabled (slow XUL tree scrolling performance)

Thanks for the update. I just tried Thunderbird 111 beta 2 "Supernova" on Ubuntu 22.04 but unfortunately the situation (laggy UI, very high CPU usage on moving mouse cursor in message pane) is still the same. Let's hope the next version will improve on that.

I tried the latest Thunderbird 112 beta 6 and unfortunately the situation is still the same. I also managed to capture a profile of simply moving the mouse cursor vertically across the message pane window. My CPU usage goes up to 25% (on a 4-core CPU) while doing so: https://share.firefox.dev/3zvwCZH

I am having the same issue with ~25% CPU usage when hovering over the messages list and from what I can observer this is somehow related to the HiDPI monitor I am using (27' LG, 4k)?

OS: Fedora 37
TB: 102.9.1
Nvidia 3060Ti + X11 (Also tested this with an AMD RX 580 and X11 and Wayland - same issue)
Ryzen 5 3400G (4 cores/8 threads)
16G Memory

Also recorded a profile: https://share.firefox.dev/3MNOpmA

I have another Fedora 37 system at work (i7-8700 w/ onboard graphics) and a 1440p monitor and here I have no issues at all. I hope this can be fixed in the not so far future - TB is really laggy at this point for me :-/

(In reply to Fabian Rodriguez:MagicFab from comment #13)

I see at least two reports confirming this in Mozilla Thunderbird support, including Windows, Mac and GNU/Linux - and I have the same problem (TB 91.1.2 on Windows 10).

This makes Thunderbird slow to the point it can't be used normally.

A possible workaround was mentioned here :
https://support.mozilla.org/en-US/questions/1347196#answer-1435915

If I go to preferences --> config editor and search for the entries:

gfx.webrender.all
gfx.webrender.force-disabled

Switch the first one to false (it was already switched to false) and the second one to true (I switched this one manually)
everything works smooths and no cpu usage jumps happen.

I suggest raising importance/severity. People upgrading seldom backup their Thunderbird profile and when this happens, all the usual "Thunderbird is slow" are being tried without a solution, bringing a user closer to stop using Thunderbird and go to other options.

A few references to people reporting this problem :

The mentioned parameter (gfx...force-disabled) is gone from configuration in 102 . Reinstating the parm helps some but doesn't fix the 100% CPU utilization. (5.15.0-52-generic #58~20.04.1-Ubuntu SMP on Intel Core i7-2760QM)

(In reply to Sebastian from comment #40)

I am having the same issue with ~25% CPU usage when hovering over the messages list and from what I can observer this is somehow related to the HiDPI monitor I am using (27' LG, 4k)?

OS: Fedora 37
TB: 102.9.1
Nvidia 3060Ti + X11 (Also tested this with an AMD RX 580 and X11 and Wayland - same issue)
Ryzen 5 3400G (4 cores/8 threads)
16G Memory

Also recorded a profile: https://share.firefox.dev/3MNOpmA

nsTreeBodyFrame::PaintCell
nsTreeBodyFrame::PaintImage
nsMsgDBView::GetCellProperties

Did anybody try to start with a clean profile restoring previous and reproduce the error?

Tested with a clean profile and thew new 115b1. Problem is still the same ("feels" even slightly worse, although I don't have hard measurements on that).

Version 102.12.0 seems to have fixed the issue on my setup (Debian 11.7, Xfce, AMD Ryzen 4750u with integrated graphics in a Thinkpad T14 AMD Gen 1). The message list highlighting is just as responsive as the folder list now. It still uses quite a bit of CPU when moving the mouse over the list, however, it's snappy and responsive now - the lag I was experiencing before seems to be completely gone.

(In reply to Adi from comment #46)

Version 102.12.0 seems to have fixed the issue on my setup (Debian 11.7, Xfce, AMD Ryzen 4750u with integrated graphics in a Thinkpad T14 AMD Gen 1). The message list highlighting is just as responsive as the folder list now. It still uses quite a bit of CPU when moving the mouse over the list, however, it's snappy and responsive now - the lag I was experiencing before seems to be completely gone.

I spoke too soon. A few hours later, it has degraded back to the old state. Nothing changed, it just started performing poorly again. I've also rebooted the computer, didn't run anything besides Thunderbird, and there is nothing I can do to get it fast again.

It seems the only time it was ever fast was immediately after upgrading the version from apt, no reboot. It was definitely fast and smooth for a few hours. Maybe this gives a hint? Just the fact that it CAN be fast? The CPU usage seems to be the same, but UI responsiveness is very different.

Tested with a clean profile and TB 115 and I still see the same high CPU usage as with all previous beta releases. Is there anything we can do to help move this higher in the priority list of the developers?

After another minor version upgrade, it was fast again. Upon switching to a new folder, it became slow, and remained slow.

I managed to capture 2 profiles, where you can see fast vs slow, same instance of Thunderbird, only difference is having switched to another mail folder then back to the original one.

fast:
https://share.firefox.dev/3NPoVnU

slow:
https://share.firefox.dev/3PZLCbH

Maybe this means something to someone, but to me it doesn't even seem to be related to WebRender.

(In reply to Adi from comment #49)

slow:
https://share.firefox.dev/3PZLCbH

activity in nsIAbDirectory.cardForEmailAddress ?
Also, are you using the cardbook addon? Problem reproduces without it?

Flags: needinfo?(adm)

(In reply to Wayne Mery (:wsmwk) from comment #50)

(In reply to Adi from comment #49)

slow:
https://share.firefox.dev/3PZLCbH

activity in nsIAbDirectory.cardForEmailAddress ?
Also, are you using the cardbook addon? Problem reproduces without it?

I owe you a beer :-)

Disabling cardbook add-on has resolved my lagging message list. It's not perfect, but it's fast now. If I toggle the message pane with f8, make the window really wide, it's still laggy, but I never use Thunderbird this way, and the lag is nothing compared to the lag I had with cardbook enabled.

In my case, I have no add-ons installed and tested with an clean profile. Compared to Thunderbird 91 the UI is laggy and uses about a factor 2 more CPU when hovering over the entries in the message pane.

(In reply to Frank from comment #52)

In my case, I have no add-ons installed and tested with an clean profile. Compared to Thunderbird 91 the UI is laggy and uses about a factor 2 more CPU when hovering over the entries in the message pane.

indeed, CPU usage is high and it's not as snappy as with version 91, but it's much better than I was experiencing, where UI would take about 250ms to update because of the cardbook addon. I still hope it gets fixed properly.

Also, it's not only the messages pane which is laggy. If you stretch the folders pane to be really wide, that one is laggy as well.

I tried to narrow this down a bit and made tests with several versions including beta releases. For me the problem starts when switching from

88.0b3 (snappy, fast)
to
89.0b1 (slow, high cpu usage)

I was trying to build a version for all the commits (revisions in mecurial?) in between to narrow it down further but was only successful for the latest 115 version so far. I'll keep trying, though. If someone could confirm, that the "laggyness" was introduced in between those versions, this would already be quite helpful. Archived releases can be found here: https://archive.mozilla.org/pub/thunderbird/releases/

And if someone is more familiar with building Thunderbird and mercurial (hg) version control, maybe he/she can help out building the revisions in between those releases?

The automation of https://mozilla.github.io/mozregression/quickstart.html will make the job much easier

(In reply to Wayne Mery (:wsmwk) from comment #55)

The automation of https://mozilla.github.io/mozregression/quickstart.html will make the job much easier

This helped, thank you! I was able to narrow it down a bit further to

48:20.61 INFO: Last good revision: 036520a38d2b3d46fb31cf93f89d3545242feac5 (2021-01-27)
48:20.61 INFO: First bad revision: 0f4f1c5ca5d305dd600f759c69737e43478e6777 (2021-01-28)

So some commit in between 2021-01-27 and 2021-01-28 in the codebase of firefox or thunderbird is causing the issue. However mozregression then does not find any builds in between and stops with

48:27.72 INFO: There are no build artifacts for these changesets (they are probably too old).

Now for the Firefox code base, that means 399 revisions and for Thunderbird 20. 😮‍💨

Any suggestions how to tackle this further?

Is this still reproducible with the latest 115.2 release?
We went through some pretty in-depth optimization and it should behave much better.
Even more improvements are on the horizon in the upcoming betas.

With these settings reverted back to normal

gfx.webrender.all
gfx.webrender.force-disabled

Switch the first one to false (it was already switched to false) and the second one to true (I switched this one manually)
everything works smooths and no cpu usage jumps happen.

I can still reproduce unusual high CPU usage. There is no perceptible lag, but CPU usage still jumps to about 75 % on my end. To compare, continuous scrolling of websites in Firefox, even complex ones, consumes less than 25 % of CPU.

So, the claim “behave much better” might be true, but the mouse-over effect still seems excessively wasteful of resources.

You need to log in before you can comment on or make changes to this bug.