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.
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.
*** Bug 121347 has been marked as a duplicate of this bug. ***
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.
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.
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 ?
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.
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...
I forgot: I'm using kontact 1.2 / kmail 1.9.1 from Debian/SID
*** This bug has been confirmed by popular vote. ***
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.
I forgot as well: kmail 1.9.3 and KDE 3.5.3 on a Kubuntu 6.06 system.
(sorry for the bug spam) Why was I removed from the CC list ?
oops, I am sorry, I think that was me. misunderstood some functions here...
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...
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.
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.
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?
I have 1.9.4 (and 1 GB of RAM) and the problem exists.
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
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
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?
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.
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
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
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.
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.
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.
*** Bug 142336 has been marked as a duplicate of this bug. ***
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.
This is still a problem for me using Kubuntu 7.04/KDE 3.5.6
Actually it became a problem again the last few weeks.
*** Bug 144475 has been marked as a duplicate of this bug. ***
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."
*** Bug 133372 has been marked as a duplicate of this bug. ***
*** Bug 123977 has been marked as a duplicate of this bug. ***
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.
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.
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.
*** Bug 135788 has been marked as a duplicate of this bug. ***
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.).
*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.
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.
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).
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).
It sounds like you have "Smooth scrolling" enabled. This loads the system a bit though it shouldn't be really sluggish.
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.
I still experience this with open source drivers (radeon, radeonhd), which don't even support compositing (at the moment). On Ubuntu Jaunty (pre-release).
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.
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?
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.
I can say the same after upgrading my NVidia drivers to version 180.37: Arrow keys work now, page up/down is still slow.
I have upgraded both KDE to version 4.2.2 and the NVidia driver to 180.44. Now it works perfectly!
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.
I had the same problem, but apparantly after upgrading the NVIDIA driver everything became smooth.
*** Bug 206967 has been marked as a duplicate of this bug. ***
*** Bug 183389 has been marked as a duplicate of this bug. ***
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
I don't see this problem anymore. Does anyone here still have it with a recent (KDE 4.4 or later) version of kmail?
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.
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
I have this problem on KDE 4.5.1/Kmail 1.13.5, NVidia 256.53 driver is installed.
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
*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.
My solution is to use a theme other then Oxygen. QTCurve seems to work without any issues.
Anybody care to mark this bug as FIXED? I'm pretty sure this went away many versions ago.
I haven't experienced this problem in the last few months using KDE 4.7-4.8
Thanks for the feedback. Closing