message list slow scrolling

[Daniel Eckl]

Hi!

I'm on kubuntu dapper and using thunderbird as mail program.

When scrolling the message list of a folder, I have redraw rates of about 5 to 10 redraws per second. In other words: The list scrolls very slow and is very unresponsive.
CPU goes up to 100% while scrolling.

I tested this with a empty profile just filled with about 100 mails in the local inbox. No extensions, no themes, no IMAP connections, no nothing.

I tested this with vanilla thunderbird downloaded from mozilla.org, too and there the problem shows up, too. So it might be related to something else I don't see yet.

I changed my GTK theme to default instead of gtk-qt. Looks ugly, but problem still persists.

Interestingly when scrolling the message preview pane or an opened message, scrolling is smooth, fast and very responsive. So graphic and rendering subsystems cannot be involved into the source of the problem I think.

Before testing dapper I used thunderbird on SuSE 9.1 and there were no problems scrolling in message lists up to 20.000 mails. So it should be able to do that fine on dapper, too. My hardware is absolutely sufficient (Athlon XP 2800+, Geforce 6600 GT, nvidia closed source driver configured correctly)

Any ideas?

Best,
Daniel

[Nevermore (ward-jake)]

I'm having the same problem. I'm on an Athlon 64 3400 with Geforce 7800GT, so I would hope my hardware can handle it. I'm on 64-bit Breezy.

I compiled my copy from source for 64 bit. I previously used the version from Ubuntu's repository (1.07 I think) without problems.

[Daniel Eckl (daniel-eckl)]

I can't exactly tell when, but the problem has vanished.

So I cannot tell if the solution was an update to xorg or otherwise...

@Nevermore: Can you confirm with actual update level?

[Dean Sas (dsas)]

can anyone verify that this still happens?

[Andrew Foster (andrew-solutionsfirst)]

Hi,

I have been experiencing this behaviour after upgrading to Dapper Beta and it now continues using Dapper stable. At one stage I did an strace and noticed that thunderbird was doing a stat() on /etc/localtime dozens of times per second while scrolling through the message list.

Scrolling in other applications and also message windows etc is fine, it's very specific to the message list itself.

Happy to provide any information about my system that you might find useful - it makes quite a big impact on how "nice" Thunderbird is to use :)

Cheers,

- Andrew

[Andrew Foster (andrew-solutionsfirst)]

Further to my previous comment:

 * I'm currently running mozilla-thunderbird 1.5.0.4-0ubuntu6.06 with mozilla-thunderbird-enigmail 0.94-0ubuntu4.1 and no other Thunderbird extensions (at least no extensions reported in the list. I may have tried to install extensions in the past but there are none there now). I'm using a Gnome desktop (standard Ubuntu)

 * I have tried using the free nvidia driver instead of the proprietary one -- no change

 * Creating a new user on my machine and running Thunderbird to see if the problem exists for them (config problem?) -- no change

 * The behaviour does not change depending on the quantity of messages in the folder being viewed (I have folders containing between 5 and 4000 items).

 * I primarily use a single IMAP account but I copied 200 messages to my local inbox and scrolling in this list does not change the behaviour.

 * Continually scrolling up and down does work the CPU very hard (but not in the message list or other applications)

Hope that helps

- Andrew

[Andrew Foster (andrew-solutionsfirst)]

Hi again

I've also noticed that about 5 out of 6 times when I click on the field/column selector (tooltip being "click to select columns for display") it won't respond unless I depress the button very slowly and deliberately (in terms of holding the mouse button down).

- Andrew

[Ilja Sekler (ilja-sekler-)]

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.

[Ilja Sekler (ilja-sekler-)]

The problematic place is http://lxr.mozilla.org/mozilla1.8/source/mail/themes/qute/mail/mailWindow1.css#852

[Ilja Sekler (ilja-sekler-)]

http://lxr.mozilla.org/mozilla1.8/source/mail/themes/qute/mail/mailWindow1.css#353 after the latest checkins from the Bug 362560, Bug 278096 and Bug 360591 for now.

[Dean Sas (dsas)]

Is this still happening in Edgy or Feisty? Can anyone else reproduce?

[Daniel Eckl (daniel-eckl)]

Problem keeps gone for me. It was gone for good on dapper and didn't appear on edgy (fresh install) at all for me.

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

Assigned to Mozilla Team

[Andrew Foster (andrew-solutionsfirst)]

Problem is gone after upgrading to Gutsy.

[maxauthority (stubenschrott)]

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 Magnusson (martin-blecket)]

For me, this problem started after upgrading to Gutsy, and it persists in Hardy. All other scrolling (including message previews in Thunderbird) is fast, but scolling the message list is slow, I'd say less than 5 frames per second. I have tried both with the nv and the nvidia driver, and the problem is the same. I have also tried this on two computers, one laptop and one stationary. The behaviour is the same on both.

[huiii (a00ps)]

i can to confirm this slow scrolling behaviour since fresh install hardy.
i did not have this problem from dapper to gutsy.
: folder / message list is very choppy / slow,
: previews fast, normal.

[huiii (a00ps)]

ps:
: delayed (1-2sec) right-mouse-click-menu

[Vseerror (vseerror)]

Martin, are you linux?
Ilja, do you still see this on trunk?

[maxauthority (stubenschrott)]

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.

[Ilja Sekler (ilja-sekler-)]

(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.

[Vseerror (vseerror)]

does the workaround in comment 0 still "fix" the problem?

[Ilja Sekler (ilja-sekler-)]

(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).

[Craig Ringer (ringerc)]

This issue is a drastic problem on Hardy when users work remotely over SSH-forwarded X11 or direct network X11. Thunderbird is essentially unusable, with message list scrolling updates taking up to a couple of seconds to complete.

The issue appears to be almost entirely with the theme. If I switch the users to a (non-packaged) theme called Whitehart:

https://addons.mozilla.org/en-US/firefox/addon/364

then while the UI is ugly performance becomes quite acceptable.

Performance issues exist in:

- The message list (awfully slow scrolling and updates)
- The mailbox list (only an issue if you have LOTS of mailboxes)
- Prefs & accounts settings windows & other dialogs (slow redraw; not a big problem)

The really major issue is the unusably slow message list.

The upstream theme is almost or exactly as bad, so it's not specific to the ubuntu theme. The users never used to have these performance issues with older 2.x versions of Thunderbird on Debian 4.1 - could it be related to the switch to Cairo for GTK?

It's not the GTK theme; switching GTK themes has no detectable effect.

[Craig Ringer (ringerc)]

More info:

There's no detectable performance issue with local X11 (`radeon' driver).

Remote displays have incredibly slow message scrolling with the default tbird theme. Message list scrolling is still a bit slow with the whitehart theme, but no longer completely awful. Most of the remote displays are Via C3 700MHz machines with Via Unichrome graphics and 256MB of RAM, running the Hardy LTSP environment with the Openchrome video driver. There are also two Intel Core 2 Duo 2.4GHz machines with GMA3100 video and 2GB of RAM using the `intel' driver and the same LTSP environment that also suffer from the problem. Yes, I know it's wrong to use them for thin clients, don't ask.

I have no thin clients that do not have the issue.

[tobiasly (tobiasly)]

I have this issue on a fresh install of Hardy, with nvidia accelerated drivers. As mentioned elsewhere, only the message list shows the issue; other scrolling within Thunderbird is fine.

This is very terrible to the point of being unusable. I'm surprised this hasn't been addressed yet since it's been an issue for over two years!

[Dille (hpalmroos)]

Same here. Scrolling the message list is very frustrating. When I press the arrow down/up keys the list scrolls almost 1 message per second rate. CPU usage is 100% during this time. Thunderbird is almost unusable because of this. Scrolling through the spam is very VERY frustrating.

Scrolling in the message-body window is very smooth, no problems at all. Just the message/subject list is slow as hell.

My work machine specs are crappy: 1GHz Celeron with 512MB PC133 memory and GF 4 MX graphics card, but 1GHz machine should be able to handle simple list-scrolling :). I'm using Nvidia's closed source drivers and the screen resolution is 1024x768 24-bit. I tried lowering the bit depth but it didn't help anything at all.

Otherwise the thunderbird and Gnome desktop in general works very well. (As well you could expect from machine like this).

Gnome version is 2.22.2. All the current Hardy Heron updates are applied. Linux version is:
 2.6.24-18-generic #1 SMP Wed May 28 20:27:26 UTC 2008 i686 GNU/Linux

Sorry for the little information I could give.

[Vseerror (vseerror)]

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?

[Nikolay Shopik (shopik)]

I see high cpu usage when using arrows and scrolling but less cpu usage.
version 3.0a2pre (2008060703)

[maxauthority (stubenschrott)]

> 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.

[dmuir (dmuir)]

I've had this problem since Edgy (now using Hardy).
Tried it on two different computers and it's the same on both.
It works fine in Windows and in MacOSX.

I've also noticed that dragging/dropping a message from the list to a folder is quite slow as well. I have to click and hold on the message for about a second, then drag over to the folder and hold it there for another second, then let go.

[oxymoron (miropetrak)]

I've had the same problem. But changing theme solved that for me.

[dmuir (dmuir)]

What theme did you install? I've installed a few, but so far, I've only found the Mac based themes have relatively smooth scrolling.

[dmuir (dmuir)]

Please vote for this issue at:
https://bugzilla.mozilla.org/show_bug.cgi?id=356201

It looks like it's a problem with XUL, and the problem still exists with Thunderbird 3.

[David-davidkmuir (david-davidkmuir)]

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.

[Benjamin Schindler (bschindler)]

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

[Vseerror (vseerror)]

cc: some linux ppl for comment

David Muir in comment #12:
> .... Switching to the classic view helps immensely

errr, switching from what?

[David-davidkmuir (david-davidkmuir)]

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.

[Mkmelin+mozilla (mkmelin+mozilla)]

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%).

[Tomasz Chomiuk (t-chomiuk)]

yes, this bug is a major problem for us since we switched to linux ;-(

[malikons (shiraz-malik)]

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.

[David-davidkmuir (david-davidkmuir)]

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...

[Tiodrakul (tiodrakul)]

Same problem here, and using Thunderbird 3.0b1. I have lots of mail messages on list and then scrolls like a old turtle =/

[maxauthority (stubenschrott)]

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?

[Benjamin Schindler (bschindler)]

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

[Philringnalda (philringnalda)]

(In reply to comment #22)
> I assume everybody using TB on linux is affected

Why?

[Benjamin Schindler (bschindler)]

(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"

[kmoffat (kmoffat)]

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.

[kmoffat (kmoffat)]

(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.

[kmoffat (kmoffat)]

Just installed the real "Firefox". Same problem.

[mbana (m.bana)]

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

[mbana (m.bana)]

I can't believe more people haven't noticed this. It's quite noticeable with a large inbox.

I've failed a bug report on https://bugzilla.mozilla.org/show_bug.cgi?id=356201.

[Bugmail-asutherland (bugmail-asutherland)]

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.

[David-davidkmuir (david-davidkmuir)]

This happens with a stock install (no extensions or extra columns).

[mbana (m.bana)]

likewise.

[Gogool (gogool)]

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+

[Nick-3rddimensiondesign (nick-3rddimensiondesign)]

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?

[mbana (m.bana)]

I'm amazed that only 33 people have noticed this.

[Geryon (nick-demandred)]

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.

[Micah Gersten (micahg)]

Marking this Triaged as we have an upstream bug.

[Vseerror (vseerror)]

(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?

[Ilja Sekler (ilja-sekler-)]

Created attachment 429413
strace output when scrolling a big mail folder (bzip2 compressed)

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

[Bugmail-asutherland (bugmail-asutherland)]

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.)

[Ilja Sekler (ilja-sekler-)]

(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.

[Vseerror (vseerror)]

(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

[Ilja Sekler (ilja-sekler-)]

Created attachment 488052
sysprof output when scrolling message list

(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

[Vseerror (vseerror)]

ludo, asuth, anything notable in the sysprof?

[Bugmail-asutherland (bugmail-asutherland)]

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.

[Vseerror (vseerror)]

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?

[Bugmail-asutherland (bugmail-asutherland)]

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...)

[Helmo (helmo)]

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.

[Vseerror (vseerror)]

Is this still seen on linux in version 24 or 31 or nightly build?
(in safe mode of course)

[Martin Magnusson (martin-blecket)]

I don't see this issue anymore using Thunderbird 24.2.0 un Kubuntu 13.04. I did see it back in 2008 (comment #15 above).

[Ilja Sekler (ilja-sekler-)]

(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.

[Paul White (paulw2u)]

To anyone affected by this problem,

We are sorry that we do not always have the capacity to review all reported bugs in a timely manner. This bug was reported some time ago and there have been many changes in Ubuntu and Thunderbird since that time.

The upstream bug was closed "RESOLVED INCOMPLETE" in 2015. Does anyone still see a problem related to the one that was reported using currently supported versions of Ubuntu and Thunderbird?

Please let us know if you do otherwise this bug report can be left to expire in approximately 60 days time.

Thank you for helping make Ubuntu better.

Paul White
[Ubuntu Bug Squad]

[Paul White (paulw2u)]

Upstream report showing "RESOLVED INCOMPLETE" on 2015-11-13
No comment here for over 4 years and no reply comment #74
Bug did not expire due bug watch so closing