Bug 119281 (composer_slow) - kmail composer suddenly becomes very slow
Summary: kmail composer suddenly becomes very slow
Status: RESOLVED WORKSFORME
Alias: composer_slow
Product: kmail
Classification: Applications
Component: composer (show other bugs)
Version: 1.9
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 121347 123977 133372 135788 142336 144475 183389 206967 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-12-31 00:41 UTC by Andy Neitzke
Modified: 2012-04-23 21:12 UTC (History)
27 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Neitzke 2005-12-31 00:41:40 UTC
Version:           1.9 (using KDE KDE 3.5.0)
Installed from:    Compiled From Sources
OS:                Linux

Sometimes when I am typing in the kmail composer window its response becomes very sluggish (letters appear on the screen much slower than I am typing them).  This never happens upon first opening the window, but only after typing (or editing) a few lines of text.  When it does happen it happens suddenly, and can be temporarily fixed by saving the mail in the "drafts" folder and then re-opening it.  Once in a while the problem goes away spontaneously (the composer speeds up again).

I have been having this problem for over a year, on both my desktop and my laptop (more frequently on the laptop), but I never filed a bug since I am not able to find any sequence of steps which reliably triggers the problem.  Nevertheless, I have the problem quite frequently (I would estimate that it occurs on at least 30% of mails written on the laptop).  It occurs whether or not I have automatic spell checking enabled.  I do use wordwrap and don't use HTML formatting.

I would be happy to help debug this problem but don't quite know where to start.
Comment 1 Oded Arbel 2006-03-22 15:20:42 UTC
This appears to be the same bug report as Bug #121347. I think it would be a good idea to merge them (I'd prefer this being the main and the #121347 being the duplicate).

Additionally I would like to add the the Kmail composer is indeed occasionally very slow to the point of being unusable. It happens to me mostly when replying to short emails (3 or 4 paragraphs, about a screen and some in length), in which after I remove some quoted text from the email and start writing - after writing about a paragraph or two the composer starts to get unbearably slow, to the point I need to stop touch typing because I type much faster then the composer - I can complete a sentence or two before the composer displays a couple of words.

It might be useful to note that this happens when the system isn't heavy loaded. Also I'd like to note that I use a rather large signature - 5 to 10 lines in length.
Comment 2 Ismail Onur Filiz 2006-03-22 18:30:36 UTC
*** Bug 121347 has been marked as a duplicate of this bug. ***
Comment 3 Claus Wilke 2006-04-09 07:48:17 UTC
If you experience this bug, please check what kind of a video card/driver you are using. I have one of the newer ATI radeon cards, and was experiencing a lot of sluggishness in the mail composer. Since I have switched from the open source driver to the proprietary driver, the sluggishness seems to have gone away. I also noticed X being frequently at 20-30% CPU load with the open source driver, while it is typically at most at 1% with the proprietary driver. The bug might simply be a combination of a lot of redraw events combined with unaccelerated X.    
Comment 4 Oded Arbel 2006-04-09 13:23:38 UTC
On Sunday, 9 בApril 2006 08:48, Claus Wilke wrote:
> ------- Additional Comments From wilke spamcop net  2006-04-09 07:48


> Since I have switched from the open source driver to the proprietary
> driver, the sluggishness seems to have gone away. 


I've noticed this issue with an old ATI mobility (M6) that is not 
supported by the proprietary driver, so switching to it is not an 
option for me.
IIRC, which I might be wrong here, it didn't happen with the open source 
nvidia driver. I haven't used it in a while, and with the proprietary 
driver it indeed doesn't happen.

> I also noticed X 
> being frequently at 20-30% CPU load with the open source driver,
> while it is typically at most at 1% with the proprietary driver. The
> bug might simply be a combination of a lot of redraw events combined
> with unaccelerated X.


Ok, that sounds like a plausible explanation. Can it be fixed? 
I don't see any reason for the composer to use so many drawing events 
that it overloads the CPU/X to the point where the application is 
unresponsive. I frequently use other applications to write a lot more 
text - then what usually causes the composer to misbehave - sometimes 
with formatting and such (which I would expect require more drawing) 
and none of them behave /that/ badly.
Comment 5 thomas klein 2006-04-09 13:35:27 UTC
I've noticed this issue on :

- Atlhon XP 2200 / 512Mo ram / nvidia geforce 4Mx (all sort of nvidia proprietary driver)

- PIII 750 / Ati mach64 mobility (8mo) / 380Mo ram

I don't know if it is an X related problem or just a composer problem...

It doesn't affect the same text in a kwrite or kate windows, don't the composer use the same textEdit class ?

Comment 6 John Bleichert 2006-04-20 19:24:38 UTC
I'm experiencing the same slowdown in the composer window (sluggish response to typing, CPU at 100%) with an ATI FireGL Mobility T2 and the proprietary fglrx driver. As a further data point, the composer is only "slow" when the window contains a lot of text, as in when forwarding or replying to a large thread.
Comment 7 Unknown 2006-05-11 17:00:19 UTC
I also noticed this bug and searched for a report. At first I found Bug 119632 "kontact hangs/crashes when composing new email" that maybe a duplicate of this bug here. 
Btw I'm using the fglrx driver...
Comment 8 Unknown 2006-05-11 17:01:16 UTC
I forgot: I'm using kontact 1.2 / kmail 1.9.1 from Debian/SID
Comment 9 Unknown 2006-05-11 17:03:12 UTC
*** This bug has been confirmed by popular vote. ***
Comment 10 schorf 2006-06-12 13:39:39 UTC
I am having the same problem on my Asus M6N with a Radeon 9600 Mobility and using the fglrx driver. And it is not only when editing big mails. it also occurs when only typing a few lines. 
Comment 11 schorf 2006-06-12 13:44:27 UTC
I forgot as well: kmail 1.9.3 and KDE 3.5.3 on a Kubuntu 6.06 system.
Comment 12 Oded Arbel 2006-06-12 14:14:19 UTC
(sorry for the bug spam)
Why was I removed from the CC list ?
Comment 13 schorf 2006-06-12 15:16:04 UTC
oops, I am sorry, I think that was me. misunderstood some functions here...
Comment 14 Unknown 2006-06-20 13:05:10 UTC
Just found out that the same slow down happens in Kopete (0.11.2) when you type longer messages. But I think few people will notice this as one rather tends to write shorter messages in ICQ & co. But I just wrote a rather longish one...
Comment 15 Vivien Mallet 2006-08-30 14:05:14 UTC
I have the same problem sometimes with KMail 1.9.3 (Debian package, etch) and half the time (!) with KMail 1.7.2 (Debian package, sarge) which I actually decided not to use anymore. I am running KMail 1.9.3 on my laptop, which includes an ATI Radeon Mobility X700 managed by the proprietary drivers. I am running KMail 1.7.2 remotely over SSH. I launch it from my laptop on a remote Dell computer (I don't know which video card). When I use KMail directly on the Dell computer, I do not experience the problem. It appears through my laptop only.

I would want to provide a few details. First, KMail composer becomes indeed very slow, but not in all composers. A new composer will run perfectly (at least for one minute or so) while the slow one is still open. I sometimes finish to write an email in another composer...

Second, the composer gets quite suddenly slow and, after some time, most letters appear twice on the screen. If I press 'a', I get 'aa'. The good point is that backspace does the same so that I can remove my two 'a' with a single backspace. :) Needless to say that it is unusable. I had to stop using KMail remotely and I switched to Thunderbird which is very heavy (especially through SSH) but still usable...

I noticed that even if the composer is slow and is generating duplicates, this is not the case at all for the above line edits (Subject, To, Copy to, etc.). They behave perfectly.
Comment 16 Chris Vigelius 2006-09-05 12:14:16 UTC
same problem here, Thinkpad T60 with SuSE 10.1 and proprietary ATI X driver. Killing klipper (as proposed in Bug 35073) does not solve the problem, but closing the mail and opening it again does. 

I can confirm that it does NOT take a long mail for the problem to occur (only a few lines are sufficient), and that it does not depend on whether the mail contains HTML or not.
Comment 17 schorf 2006-09-05 12:25:04 UTC
I haven't had the problem for some weeks now. maybe it got solved with kmail 1.9.4? about the same time i upgraded my RAM from 512 to 1265 mb. but I guess the version update did it. can you confirm this?
Comment 18 Chris Vigelius 2006-09-05 16:39:44 UTC
I have 1.9.4 (and 1 GB of RAM) and the problem exists. 
Comment 19 Anand Vaidya 2006-09-06 10:40:50 UTC
I have the same problem on an idle laptop.

HW: CoreDuo 1.66GHz dual CPU, 1GB RAM, ATI X1400 with proprietary drivers
SW: Kubuntu 6.06.1-x86, KDE 3.5.4 with Kmail - 1.9.4

I am using the option  of "use an external editor" ie. using kate. to workaround the problem.

Looking at the kate window, I was surprised to see that even normal text messages are "composed" in HTML format, I suspect this to be related to the slowdown

Regards
Anand Vaidya
Comment 20 Andreas Gungl 2006-09-06 10:55:42 UTC
Am Mittwoch, 6. September 2006 10:40 schrieb Anand Vaidya:
> Looking at the kate window, I was surprised to see that even normal text
> messages are "composed" in HTML format, I suspect this to be related to
> the slowdown


Really? Do you see the HTML toolabr in the composer window of KMail? If yes, 
please switch it of (Menu Options -> Formatting HTML) and try it again. TIA
Comment 21 Kurt Bennater 2006-09-09 22:19:58 UTC
Same problem here with old (open source) radeon driver (and KMail 1.9.4 with 768 MB RAM). This is an annoying bug which makes KMail nearly unusable for composing emails. What can I do in order to help to solve it?
Comment 22 Ingo Klöcker 2006-09-11 21:32:21 UTC
Hmm, I guess the HTML code in the external editor comes from the fact that we use rich text also for normal text messages for highlighting quoted text and spelling errors. Anyway, that shouldn't be related to this problem.
Comment 23 Franck Bourdonnec 2006-11-28 12:45:05 UTC
My contribution:
Since recent kmail (1.9.5/kde 3.5.5) I don't have anymore the problem.
Not a video driver related problem.

I was only having the problem *after* a copy/past operation.
Selection of text area on firefox page, past it in a new mail,
and depending (on what???) =>slow down.

Not annoyed with updated kde/kmail.
Franck

Comment 24 austin 2006-12-11 22:11:47 UTC
Same issue with kmail 1.9.5/kde 3.5.5.......any information I could provide to assist with diagnosing this issue?  What's weird is that I do not see any process spiking when the issue is occuring.  It always occurs after about 4 lines are typed in the kmail composer.

Austin
Comment 25 Magnus Holmgren 2006-12-13 14:30:20 UTC
If you're talking about the behaviour that CPU usage goes up to 100% for a moment after each keypress, I've experienced it with Kopete chat windows that have been open for a long time. The number of lines of text doesn't seem to matter.
Comment 26 johnny 2007-01-05 01:20:37 UTC
I experienced the same bug with kmail 1.9.5 (kde 3.5.5). I'm almost sure this has to do with the KSpell stuff. Every time i start up a composer window it also loads an "aspell" process, even if Tools/Automatic spellchecking is DISABLED.
Comment 27 johnny 2007-01-05 01:26:18 UTC
OK, i have some news. Actually, X is the process taking too much CPU while typing, so this enforces the refresh problem idea.

But there is something weird: After a few paragraph the typing gets slow and cpu goes to 100%, but wiping the whole text and starting writing from empty window still manifests the bug even after a few words. So this seems to have nothing to do with the length of the text.

Anyway there is still the "aspell" process that should NOT be there as I unselected all the options related to spell checking.
Comment 28 Thomas McGuire 2007-02-28 18:51:22 UTC
*** Bug 142336 has been marked as a duplicate of this bug. ***
Comment 29 Andy Goss 2007-04-04 06:53:17 UTC
Similar slowdown to everyone else after a few lines of text. Kmail 1.9.1 in Kubuntu 6.06. 

BUT

New aspect! If the email composer session (includes editing drafts) begins with wordwrap off (either by default or before typing) there is NO slowdown. As soon as word wrap is turned on, s-l-o-w. If wordwrap is then turned off, composer remains just as slow for the rest of the composer session. 
Comment 30 jsvrp.gw 2007-04-19 15:00:48 UTC
This is still a problem for me using Kubuntu 7.04/KDE 3.5.6
Comment 31 jsvrp.gw 2007-04-19 15:03:56 UTC
Actually it became a problem again the last few weeks. 
Comment 32 Thomas McGuire 2007-04-22 17:19:43 UTC
*** Bug 144475 has been marked as a duplicate of this bug. ***
Comment 33 Ray Ferguson 2007-06-03 21:18:25 UTC
Confirmed word wrap trigger.  Happens to me too.  It seems that word wrap causes a serious amount of 2D graphics load that pegs the CPUs and causes delay.

Found fix/work around.  I hesitate to call it a fix since I think it worthwhile to find out what causes the graphics load for such a simple thing as performing word wrap.

My setup: 
OpenSuse 10.2 on thinkpad t60p w/ ati FirGL 5250 and proprietary driver from vendor package repository: http://www2.ati.com/suse/10.2
ati-fglrxG01-kmp-default-8.36.5_2.6.18.8_0.3-1.1
kmail 1.9.5 on kde 3.5.5

I added 

  Option "XaaNoOffscreenPixmaps" 

to the firgl device section of the xorg.conf file as suggested here: http://wiki.cchtml.com/index.php/Performance_Issues

and the problem went away.  The option is described in xorg.conf as

"Disables accelerated draws into pixmaps stored in offscreen video memory."

Comment 34 Thomas McGuire 2007-07-12 23:37:17 UTC
*** Bug 133372 has been marked as a duplicate of this bug. ***
Comment 35 Thomas McGuire 2007-07-12 23:38:24 UTC
*** Bug 123977 has been marked as a duplicate of this bug. ***
Comment 36 Vivien Mallet 2007-09-15 23:32:47 UTC
As suggested by Ray Ferguson, I added

  Option "XaaNoOffscreenPixmaps"

This fixed the problem on my laptop which includes an ATI Radeon Mobility X700. I use KMail 1.9.6 under KDE 3.5.6, from Kubuntu Feisty.
Comment 37 jsvrp.gw 2007-09-20 22:55:19 UTC
I like to confirm the fix with Option "XaaNoOffscreenPixmaps" under the Section "Device" in xorg.conf.

I have a VIA OpenChrome on board shared memory.

Comment 38 Andy Goss 2007-12-07 01:42:47 UTC
Having moved from Kubuntu Dapper to Debian Etch, on the same machine, "VIA Technologies, Inc. S3 Unichrome Pro VGA Adapter", the problem persisted, so I applied the fix, Option "XaaNoOffscreenPixmaps" under the Section "Device" in xorg.conf. It works. 
Comment 39 Thomas McGuire 2007-12-20 23:31:59 UTC
*** Bug 135788 has been marked as a duplicate of this bug. ***
Comment 40 gmud 2008-12-08 14:26:30 UTC
I have this problem, too. And it seems it got worse with KDE 4.1 (kmail 1.10.3). If, for example I move the cursor around by holding down the cursor keys then the cursors moves very slow but the buffer of the keyboard is still filled with the move key resulting in a move of the cursor even after releasing the key. This only happens within kmail, not kate or kwrite. It happens on all my notebooks (which all have an intel graphics adapter (i810 etc.).
Comment 41 Martin van Es 2009-01-05 14:44:27 UTC
*me too* on intel GM965 on a Dell Laptop, using KDE 4.1.85 (beta2).
Composer is usable, but unacceptable sluggish for this kind of laptop (2Ghz, core2 duo).
XaaNoOffscreenPixmaps doesn't help, because the driver uses EXA for acceleration (and I guess it's not used by intel driver). Composite layer is compiz, instead of KDE's desktop effects.
Comment 42 Dimitris 2009-01-17 16:23:28 UTC
I'm experiencing the same problem as well. I tried nvidia (legacy 96.43.09 beta) and open source nv as well. The problems remains the same. If i create a new email and start typing fast, X and kmail takes up the whole cpu (Athlon XP 1800+). The same happens if i don't type anything, but i choose to reply to a message. If i press the arrow keys to move the cursor to other points within the quoted message, kmail and X have high cpu usage, making the program slow.
Comment 43 Luke Plant 2009-01-27 14:41:46 UTC
I am experiencing this as well with KDE 4.2 RC1 (Ubuntu Intrepid packages), kmail 1.11.0 -- especially trying to move around with arrow keys -- the composer cannot keep up if I hold an arrow key down for any length of time, so when I let go it always overshoots.  Editing in general is painful. This only happens in kmail, not in any other KDE editors e.g. Kate.  

For the most part it is fixed by turning off compositing in kwin, but some things remain slow e.g. PageDown button -- it looks as if page down is being simulated by arrow key presses, so every PageDown seems to take at least half a second, with a lot going on visually on the screen.

My graphics card is an "ATI Technologies Inc Mobility Radeon HD 3650", using the proprietary driver in Ubuntu (Intrepid), on a brand new powerful laptop (Dell Studio 17).
Comment 44 Luke Plant 2009-01-27 14:52:12 UTC
Additionally, the XaaNoOffscreenPixmaps fix does not work for me.  I have to disable compositing (Alt-Shift-F12 in kwin) to have a comfortable email editor, and that still does not fix the PageUp/Down problem (might be separate bug).
Comment 45 Oded Arbel 2009-01-28 12:48:15 UTC
It sounds like you have "Smooth scrolling" enabled. This loads the system a bit though it shouldn't be really sluggish.
Comment 46 Luke Plant 2009-01-28 12:59:09 UTC
No, I don't have smooth scrolling enabled (AFAIK - I can't find any way in KMail to set this).  Note that I have no problem with the message preview window, it's only the composer.
Comment 47 Luke Plant 2009-02-09 19:25:52 UTC
I still experience this with open source drivers (radeon, radeonhd), which don't even support compositing (at the moment).

On Ubuntu Jaunty (pre-release).
Comment 48 David Johnson 2009-02-12 07:00:26 UTC
I am getting this as well. Kmail 1.11.0 (4.2.0), X.org 7.4, open source "radeon" driver. It happens only when compositing (desktop effects) are turned on. Turning them off and kmail works fine. Delay between keystrokes can be as long as one second. Only Kmail seems to have this problem. It happens whether I have spellcheck on or off.
Comment 49 gmud 2009-02-12 08:56:10 UTC
In reply to David and other comments: I have this problem even without compositing turned on and with intel drivers (on two machines). The problem started when kmails behaviour to compose html messages was changed. Maybe this could be the cause?
Comment 50 Luke Plant 2009-03-07 15:56:37 UTC
I managed to improve my graphics drivers, and the problem has gone away for me.

(Details: I'm running KDE 4.2.1, Ubuntu Jaunty (pre-release), graphics card ATI Technologies Inc Mobility Radeon HD 3650, using new radeonhd driver as described here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/334101 )

So this is definitely related to hardware acceleration, but kmail is unusual in that it has such bad performance with some graphics cards/drivers, when no other text editor is like that.

BTW, the strange behaviour of page up/page down is still the same for me.  The scrolling is now fast enough to be tolerable, but it is not ideal.  I didn't see this in KDE 3.5.
Comment 51 Thomas Zell 2009-03-09 11:18:57 UTC
I can say the same after upgrading my NVidia drivers to version 180.37: Arrow keys work now, page up/down is still slow.
Comment 52 Thomas Zell 2009-04-05 20:23:24 UTC
I have upgraded both KDE to version 4.2.2 and the NVidia driver to 180.44. Now it works perfectly!
Comment 53 Arno Rehn 2009-09-12 16:40:38 UTC
I still experience this bug with KMail 1.12.90 (r1022618). nVidia driver 185.18.36. Enabling or disabling desktop effects doesn't make any difference; also the suggested XaaNoOffscreenPixmaps doesn't help. xorg-server is 1.6.3.901.
I don't have any spell-checking enabled, word-wrapping is on (disabling it doesn't make any difference).
Typing and scrolling is not only slow when there's some text in the window, it's also slow when I just start a new mail, i.e. the composer's empty. But it gets worse the more text there is in the composer.
According to 'top', CPU usage goes up to 60% when typing (on an Athlon64 X2 6000+ with 2 gigs of ram).

Out of curiosity: are you using KatePart/KTextEditor for the composer or an own editor part? Because KatePart works smoothly on my machine.
Comment 54 Dj YB 2009-11-11 13:39:26 UTC
I had the same problem, but apparantly after upgrading the NVIDIA driver everything became smooth.
Comment 55 Björn Ruberg 2010-02-06 01:07:32 UTC
*** Bug 206967 has been marked as a duplicate of this bug. ***
Comment 56 Björn Ruberg 2010-02-06 01:08:21 UTC
*** Bug 183389 has been marked as a duplicate of this bug. ***
Comment 57 ralfgesellensetter 2010-03-16 20:35:22 UTC
kmail: 1.12.4
There seem to be background processes (like sorting threads) that consume a lot of CPU time (htop shows 14% CPU on AMD 1800+).

For about a week or so, it is not even getting better after messages are downloaded and sorted. I can hardly use the editor any more :(

I don't think it is due to the ATI graphic card, it might be an issue of thread priorities. If I use other applications, I can type fluently there.

As this is for recent Debian Sid packages, I suggest to create a new bug entry rather than appending an old kmail bug.

Regards
Ralf
Comment 58 Björn Ruberg 2010-08-13 20:25:23 UTC
I don't see this problem anymore. Does anyone here still have it with a recent (KDE 4.4 or later) version of kmail?
Comment 59 Tilman Klaeger 2010-08-14 00:24:24 UTC
I watched this problem on KDE 4.5RC2. The KMail composer was so slow, I could type a text and watch the computer write it! But in KDE 4.5 final this problem seems to be gone. (Everything on Arch Linux). Maybe some debugging symbols caused that extrem slowdown.
Comment 60 Magnus Johansson 2010-08-22 12:19:24 UTC
This still happens for my girlfriend. I'm logged in on tty7, she's on tty8. I have compositing enabled, she does not. I don't experience this problem, she does. It is exactly the same hardware and software: Intel G35 graphics, intel drivers 2.9.1. We are both running KDE 4.4.5 and KMail 1.13.5
Comment 61 Pal Körössy 2010-09-07 23:04:25 UTC
I have this problem on KDE 4.5.1/Kmail 1.13.5, NVidia 256.53 driver is installed.
Comment 62 Mathias 2010-09-08 12:56:30 UTC
I'm encountering this problem just since a couple of days (could be related to mysql-update/ akonadi-problem?). symptoms are similar:

-in about the half of cases opened composer windows become unresponsive for ca. 15 sec.: no input by mouse or keyboard is accepted. after this time, all the actions taken during those seconds, are carried out. different to other reporters here: there is NO additional CPU usage during the phenomenon - all 4 proc's remain idling. also no unusual HDD acitivity. I can switch to other applications, even to the main kmail window, and mouse & keyboard are working flawlessly there.
-at the same time, the mouse cursor disappears only above the composer window.
-additionally, sometimes kmail needs an unusual long time to send a mail (hanging for around 10 sec. between clicking on "Send" and the composer window to be closed).

Please tell me if I'm wrong with this problem in this thread. I wanted to avoid dups.

System:
kmail 1.13.5
KDE 4.4.5
Gentoo - compiled from sources
kernel 2.6.34-gentoo-r6
Intel i5-graphics (on proc) with i915-driver
Comment 63 San 2010-09-10 13:59:58 UTC
*same issue here* on a Dell laptop with fresh kubuntu 10.04
(but old /home folder)

in fact I have been having this slowness problem with kmail for *years*. But the problem is that it does not happen all the time, and I don't know what triggers it. Recently I noticed that turning off compositing (ALT-SHIFT f12) solves the problem, and when turning compositing ON again, the problem does *not* reappear ! (at least not immediately).

I'm willing to do some more testing to help, but don't know how.
Comment 64 Jon Skanes 2011-01-28 04:35:06 UTC
My solution is to use a theme other then Oxygen.  QTCurve seems to work without any issues.
Comment 65 Jon Skanes 2012-04-15 19:35:40 UTC
Anybody care to mark this bug as FIXED?  I'm pretty sure this went away many versions ago.
Comment 66 Pal Körössy 2012-04-16 07:57:23 UTC
I haven't experienced this problem in the last few months using KDE 4.7-4.8
Comment 67 Christophe Marin 2012-04-23 21:12:32 UTC
Thanks for the feedback. Closing