Closed Bug 356201 Opened 18 years ago Closed 9 years ago

message-list pane: slow mousewheel scrolling and scroll bar arrows, high cpu

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: bugzilla.i.sekler, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [needs profile])

Attachments

(2 files)

strace output when scrolling a big mail folder (bzip2 compressed)
43.80 KB, application/x-bzip
Details
sysprof output when scrolling message list
116.57 KB, application/x-gzip
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060925 Firefox/2.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/00000000 Thunderbird/2.0b1pre The message-list pane reacts with a visible delay on mousewheel scrolling. Linux-only. checkout start: Di 10. Okt 19:32:01 CEST 2006 Reproducible: Always Steps to Reproduce: 1. Open a mail folder containing a lot of messages to make scrollbars appear 2. Scroll the message list with the mousewheel 3. Actual Results: There is a perceptible delay between the movement of the mousewheel and the movement of the message list. Expected Results: No delay, like the scrolling works in the message pane. Looks like a side effect of Bug 345887. Putting #threadTree treechildren::-moz-tree-row(odd) { background-image: none !important; } into userChrome.css works around the underlying issue.
Version: unspecified → 2.0
That code snippet definitely helps a little, but the tree still is not as fast as known from other mail applications/list views while scrolling. Using thunderbird3.0alpha.
Martin, are you linux? Ilja, do you still see this on trunk?
Assignee: mscott → nobody
Wayne: yes, on Linux. Also using a very recent nightly, I can still confirm that it is not super fast. With this userChrome.css hack it's however definitely usable on a 330mail folder. I also noticed a big difference, when Thunderbird is in "wide" or "classical" view, the display is nearly instant as expected, only with the bigger "vertical" view, the performance problems become apparent, when the mail view is >1000px high on my screen.
(In reply to comment #4) > Ilja, do you still see this on trunk? Yes, though it is less severe than on the 1.8 branch. The delay seems to be proportional to the number of messages fitting into the message list pane. That is why vertical view is more affected than the classical view with message pane (F8) turned on. Turn the message pane off and there is no difference anymore. Further, the effect depends strongly on the available 2D graphics hardware acceleration provided by the video driver. For example, nv is much worse than nvidia, making nv better for reproducing the issue.
does the workaround in comment 0 still "fix" the problem?
(In reply to comment #7) > does the workaround in comment 0 still "fix" the problem? No, but it improves the situation a lot. The workaround reduces the delay very clearly, though the scrolling still doesn't feel same solid as with Thunderbird 1.0 for example. Using scroll buttons instead of the mousewheel makes it more difficult to feel the problem but much more easy to measure it: I have a mail folder with 281 messages, 46 fit into the message list pane window if the message pane is turned off. Time needed to scroll from bottom to top pressing the upper scroll button: without the workaround: 28 seconds; with the workaround: 13 seconds. Tested with Thunderbird 3.0a2pre (X11/2008052803).
Do you also see high CPU? I see high cpu in 2.0 and trunk hen using arrows of the vertical scroll bar. and as Ilja says it's proportional to # messages in thread pane. Don't see high cpu in version 1.0.7 (20050923) - highest is ~10%. Don't see this when dragging slider. Also see bug 348507, but according to Samuli the partial workaround here doesn't affect 348507 - so marking it dependent (seems likely these are the same, or related) xref bug 310912 which suggests problem is "treebody has transparent background by default." So is this XUL performance issue?
Blocks: 348507
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
OS: Linux → All
Hardware: PC → All
Summary: message-list pane: slow mousewheel scrolling → message-list pane: slow mousewheel scrolling and scroll bar arrows, high cpu
I see high cpu usage when using arrows and scrolling but less cpu usage. version 3.0a2pre (2008060703)
> So is this XUL performance issue? Seems so. I also tested with Options->Advanced->Certificates->View Certificates and even with Firefox3, View Cookies. While the problem isn't that noticeable there, I certainly do view a difference in perceived scrolling speed whenever those listviews get larger. Also a very interesting point is, that not only vertical size, but also horizontal size of the view. I also tested with a "native" GTK+ app (file-roller), there even at 1680x1050, the listview scrolls absolutely fluid, so it's not a theme/graphics card issue. Slightly off-topic, but XUL performance under linux is still very bad, if I open the File menu, and keep hitting <Right>, it is very slow, compared to native gtk apps where the menus just fly by.
I've been having this issue with Thunderbird on Ubuntu. Would love to see this get fixed. Switching to the classic view helps immensely, but not really a solution. Also noticed similar performance issues in Firefox. Should this be lodged as a XUL bug instead? Hardware wise, I'm running a Core2 Duo T7800, 4GB ram and a Quadro FX 570M. Also had the same issue on a Athlon 64 3200+, 1GB ram and a 6600GT.
I've got this issue on linux since switching to 2.0 and higher. I fear that most people at least on linux are affected by this bug, but they don't show up because they think it's normal. I'm running gentoo-64bit
cc: some linux ppl for comment David Muir in comment #12: > .... Switching to the classic view helps immensely errr, switching from what?
Switching from Vertical View (sorry, forgot that the classic view is the default). I like the vertical view, but runs too slow. The mac based themes also seem to be a bit faster.
I never noticed, but dragging the scroll bar up and down repeatedly does make the cpu go up quite a bit (at least to ~20%).
yes, this bug is a major problem for us since we switched to linux ;-(
I am not sure why this is not the top priority. True; this is not a show stopper but it is making people hate TB and is very annoying when working with tons of emails every day. Is there any any successful workaround? I couldn't find userChrome.css so couldn't do that. I am running TB 2.0.0.17 on RHEL5.2. Changing the theme to whiteart and view to classic did make significant difference but a solution is still highly anticipated as this is forcing users to change the settings against their will and make TB look like a CLI tool.
userChrome.css doesn't exist by default. You have to create the file in the chrome folder under your profile ~/.mozilla-thunderbird/{profile}/chrome The Linux version of XULRunner needs a lot more work. Firefox has similar issues...
Same problem here, and using Thunderbird 3.0b1. I have lots of mail messages on list and then scrolls like a old turtle =/
I updated my old PC (Pentium4, 1GB RAM, GeForce 5900FX with 96.xx drivers) to a new one (corei7, 6GB RAM, GeForce 9600GT, 180.27 drivers) and the problem seems to be fixed. I am not sure if the 180.xx drivers alone did it, or just the new pc, but maybe this has been a nvidia driver issue?
I have access to another machine - a quad-core where scrolling is almost smooth. However: - CPU usage spikes enormously when scrolling. The faster cpu is just able to handle the load good enough - Newer nvidia drivers certainly don't fix the problem: At the mozilla devs: this bug is now over 2 years old and there is not even a sign of a solution. Do you even care about linux support? I assume everybody using TB on linux is affected
(In reply to comment #22) > I assume everybody using TB on linux is affected Why?
(In reply to comment #23) > (In reply to comment #22) > > I assume everybody using TB on linux is affected > > Why? I use TB on about 4 different linux machines - one being a RHEL 5.something, two of them being Gentoo with completely different HW-configurations and a Debian machine and all show the issue. As others in this thread have stated, scrolling in other "native" gtk apps just scroll smooth - on all platforms. I'm a Software Engineer myself - so for me the likelyhood of this being an issue in Thunderbird (or XulRunner for that matter) is very high. That's why I said "I assume"
FYI: I'm on Debian Sid, and my problem is with "Iceweasel", which is the Debian version of Firefox. (Only the names have been changed). Extremely slow scroll of windows using mouse or keyboard.
(In reply to comment #25) > FYI: I'm on Debian Sid, and my problem is with "Iceweasel", which is the Debian > version of Firefox. (Only the names have been changed). Extremely slow scroll > of windows using mouse or keyboard. However, no problem with Thunderbird.
Just installed the real "Firefox". Same problem.
Confirming bug. I'd also like to add that I've been considering switching to Evolution, but it has a few features missing. I'd advice trying Evolution to notice the difference in scroll speed. This issue is also noticeable if you compare with a native GTK(2) app. ProblemType: Bug Architecture: amd64 DistroRelease: Ubuntu 9.04 NonfreeKernelModules: nvidia Package: thunderbird 2.0.0.21+nobinonly-0ubuntu1.9.04.1 ProcEnviron: SHELL=/usr/bin/zsh PATH=(custom, user) LANG=en_GB.UTF-8 SourcePackage: thunderbird Uname: Linux 2.6.28-11-generic x86_64
Are people using a lot/any custom columns provided by extensions who experience these problems? Custom columns, assuming they are implemented in C++, have a non-trivial performance cost and can add up if you have a number of them.
This happens with a stock install (no extensions or extra columns).
likewise.
I also experience this bug, without any extra columns. That's exactly the problem: the Thunderbird experience is pretty bad out of the box. I'm using Ubuntu 8.10 with the "nvidia" driver and an AMD 64 3000+
I can confirm this problem! I am running Gentoo/KDE 3.5 on a fairly new and optimized system with Xorg configured well and good scrolling in FF. I've experience jerky scrolling in the Thunderbird message pane for the longest time and assumed it was "normal", as the poster above mentioned. When I saw smooth scrolling using Thunderbird on Windows machines, I noticed something was wrong. The chrome css fix described above seems to help a little, but the scrolling is still below par. Often, heavy use of fixed background images in FF can cause jerky page scrolling, and this situation feels the same way. Perhaps it is trying to render something unnecessarily, such as a background?
I'm amazed that only 33 people have noticed this.
I've been having this problem with Thunderbird for years on Linux-based systems. From Ubuntu/Debian, RedHat, SuSE and even Slackware. It seems to have no bearing on video card/drivers, processor speed etc. It's gotten so frustrating I've just switched to using Alpine. I have tested this problem on four current systems, Three Ubuntu 9.04 and 1 9.10. Two using openchrome, another intel 2.4, and the last nvidia's latest 184.xxx video drives. 2 systems are dual core athlons 3000+ and 5000+, an Athlon-m 2200+ and an intel core duo 1.8ghz (laptop). The problem is identical across all 3 systems with the same mailbox. Memory ranges on these system from 512MB to 5GB with no noticeable difference in performance in Thunderbird.
(In reply to comment #13) > I've got this issue on linux since switching to 2.0 and higher. Benjamin, et al, so this didn't happen in v1.5? has anyone attempted to confirm this is caused by Bug 345887? given that it's high cpu, might a trace be helpful?
Component: Mail Window Front End → Folder and Message Lists
QA Contact: front-end → folders-message-lists
If it still matters for TB 3.1b1pre: CPU goes high up to appr. 40% when scrolling the message list fast. Turning the date column off doesn't make any difference. gnomestripe doesn't use transparent images for odd rows and the scroll feeling is good enough for me. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.2pre) Gecko/20100224 Lightning/1.0b2pre Thunderbird/3.1b1pre
Given the contents of the strace log and your attempt at turning off the date column (given that only the stat on /etc/localtime stood out as redundant), I don't think there's anything useful in there. At this point, the only thing likely to help is a profiling run, preferably whole-system, to find what the hot spots are. You will need to make sure you have debugging symbols; assuming you are using your distribution's build, I think there should be supplementary packages that contain them. If you are using mozilla builds, then you will need to actually perform your own build with "ac_add_options --enable-debugger-info-modules=yes" in the mozconfig. Once you have that, I would suggest giving 'sysprof' a whirl... it's probably the easiest option for a first try. (Systemtap or the kernel 'perf' tool would probably be the appropriate choices for more thorough investigation/aggregation on the actual stack frames.)
(In reply to comment #38) > Given the contents of the strace log and your attempt at turning off the date > column (given that only the stat on /etc/localtime stood out as redundant), I > don't think there's anything useful in there. If the stat on /etc/localtime is redundant, it should be IMVHO avoided (maybe as well as 7795 calls gettimeofday() in the log), even if my computer is fast enough to cope with the redundant calls. I just realized that Thunderbird doesn't scroll the message list at all. It seems to repopulate the content of the message list pane line-wise on mousewheel turn or on moving the thumb in the slider, which imitates scrolling to some extent. This is the biggest difference to native applications like e.g. Nautilus and AFAIR to TB 1.0, which first generate a full list of the content of a folder and then move it pixel-wise when pulling the thumb. I'll look into profiling if it becomes definitely required, but I suspect that the root of the problem is this strange way TB simulates scrolling in the message list pane.
See Also: → https://launchpad.net/bugs/38054
(In reply to comment #39) > I just realized that Thunderbird doesn't scroll the message list at all. It > seems to repopulate the content of the message list pane line-wise on > mousewheel turn or on moving the thumb in the slider, which imitates scrolling > to some extent. this is based on observation only? or an examination of the code (static or trace while running)? or a log? > I'll look into profiling if it becomes definitely required, but I suspect that > the root of the problem is this strange way TB simulates scrolling in the > message list pane. I think it's still needed
(In reply to comment #40) > (In reply to comment #39) >> I just realized that Thunderbird doesn't scroll the message list at all. >> It seems to repopulate the content of the message list pane line-wise on >> mousewheel turn [...] > > this is based on observation only? > or an examination of the code [...]? The former, unfortunately. Later I saw that this is generally the way a tree is scrolled (<http://mxr.mozilla.org/mozilla1.9.2/source/toolkit/content/widgets/tree.xml#673>??) and thus not Thunderbird specific. "about:config" in Firefox behaves exactly the same. >> I'll look into profiling if it becomes definitely required [...] > > I think it's still needed Gzip-compressed sysprof output from a debug branch build attached. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13pre) Gecko/20101103 Lightning/1.0b3pre Thunderbird/3.1.7pre SourceStamp=be15794e4a90
ludo, asuth, anything notable in the sysprof?
sysprof says that ~48% of the time is indeed spent in the tree painting, which, as Ilja says, is basically just how the tree widget goes. The specific breakdown is spread across a number of sub-functions which suggests there is no single rogue function/hotspot going on. (Thebes does show up a bit, but font metric stuff does need to be involved...) Enhancements to the treeview to make the scrollbar operate asynchronously (or to cancel pending paints) would likely provide the greatest benefit.
what's key to reproduce - a slow machine or something else? (because I don't see slowness on any of my machines) and, is this truly fallout from bug 345887?
As Ilja says, the speed of the rendering subsystem (such as X driver) can affect things. A theme could affect things if it increases the rendering complexity, such as using gradients where none where previously used, etc. While scrolling speed where dragging the scroll thumb is important, it's not critical. As long as paging through the 3-pane is responsive, I would consider things fine. I may have noted this before, but if not... extensions providing custom columns or decorating existing columns can slow down scrolling by an order of magnitude or more, and that's basically on the extensions. (Although it would be nice if the XUL widget cached so as to avoid that...)
I can confirm that an extension can have this effect. I saw this with https://addons.mozilla.org/en-US/thunderbird/addon/quickarchiver/ When I disable the extra column it adds the scroll speed is back to normal.
Is this still seen on linux in version 24 or 31 or nightly build? (in safe mode of course)
Flags: needinfo?(nick)
Flags: needinfo?(nick)
Flags: needinfo?(ilja_sekler_)
Flags: needinfo?(david)
(In reply to Wayne Mery (:wsmwk) from comment #47) > Is this still seen on linux in version 24 or 31 or nightly build? > (in safe mode of course) My computer is too fast to expose this issue with TB 24.7.0 at least. The CPU spikes at 80% when rapidly scrolling a long message list (several thousand messages) in a maximized TB window though. On a slow machine with poor quality drivers this could still be a problem.
Flags: needinfo?(bugzilla.i.sekler)
No longer blocks: 348507
See Also: → 348507
Nick no longer sees this problem
Flags: needinfo?(nick)
If anyone still sees this using Thunderbird started in safe mode, please get a short profile per https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Thunderbird_Performance_Problem_with_G If profile is too big, then the share/upload step will fail. You must use a shorter time period, say 5-10 seconds
Whiteboard: [closeme 2015-10-10][needs profile]
If anyone still sees this problem mplease open a new bug report, and reference this bug#
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(nick)
Flags: needinfo?(david)
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2015-10-10][needs profile] → [needs profile]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: