Version: 1.3.1 (using KDE 3.2 BRANCH >= 20040204, Mandrake Linux Cooker i586 - Cooker) Compiler: gcc version 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk) OS: Linux (i686) release 2.6.3-7mdk When the Konsole history contains long enough (broken) lines in the viewport, scrolling becomes extremely slow, with visible redrawing. However, if I scroll to another region that does not contain broken lines, scrolling becomes visibly faster. And it's very slow anyway on my Mandrake 10 Centrino 1.5 GHz laptop (much slower than, say, in Kate).
Konsole is unusable with my laptop (x-terminal). When i change tabs or if there is lot of text, it's so slow that i can see lines drawn. Also resizing konsole window can take two to three seconds. gnome-terminal, xterm etc. have no such problems. It doesn't matter if i use transparent background or not. I'm currently using KDE 3.4.2 from Debian/unstable. Every other KDE application seems to work like it should. This is very annoying and konsole is currently unusable on my laptop. My 'main' computer is fast enough to use konsole, but i'm sure there is something wrong with konsole anyway.
Could you try KDE 3.5? I also would be interested in hearing if turning off the History helps/fixes these issues.
>Could you try KDE 3.5? I also would be interested in hearing if turning off the History helps/fixes these issues. > > > Sorry, can't try KDE 3.5 for now - I work on this comp... maybe when the RC is out. Anyway, I wrote a mini-benchmark. It uses the following code in Python: -------------------- import sys import string iters = int(sys.argv[1]) width = int(sys.argv[2]) s = (string.hexdigits * width) + "\n" ss = s * (iters/width) print ss -------------------- Note that the benchmarks does the printing with a single command, therefore, there should be no problems with buffering between the python process and the console itself. Here are the results for different parameters (In all the results I show the elapsed time). The first parameter is just the size of the benchmark, and the second one determines the width of the printed text (so I run it with something like "time python wideprint.py 1000000 1000"). All the runs above were executed with iters=1000000, and varying width. The time reported is the value printed by defining "export TIMEFORMAT='%R'" in bash. Width Output_to_/dev/null Konsole Konsole(no_history) xterm 1 0.179 31.556 30.117 148.428 # no wrapping 10 0.202 57.264 47.527 37.985 # wrapping into ~2 lines 100 0.306 94.222 86.642 37.240 # wrapping into ~10 lines 1000 0.144 81.101 88.994 37.667 # wrapping into ~100 lines 10000 0.307 69.729 80.660 37.017 # heavy wrapping 100000 0.127 75.450 77.561 37.360 # extremely heavy wrapping What the benchmark shows: 1. A good portion of the 30 seconds is the text rendering time proper, as taken by X server. 2. xterm is stupid when printing many short lines, and konsole is GOOD. 3. konsole behaves badly when wrapping starts to happen, and the badness increases with the amount of wrapping. 4. History has almost no effect on the konsole's performance. In addition, the Xterm version *appears* to go fast, i.e., it is redrawing the contents of the terminal very quickly. On the other hand, the konsole is redrawing very slowly, and pauses for ~0.5 seconds (gc?) every couple of seconds. I watched top during the benchmark, and the interesting thing is, it is the X server taking the time when the konsole slows down due to wrapping, implying that it's konsole's rendering code that behaves badly in this case, and not the wrapping logic per se. Created an attachment (id=12791) gsasha-1.vcf
Fixed in Konsole for KDE 4. Changed the rendering process to cut down the excessive number of QPainter::drawText() calls. Under KDE 4, Konsole's behaviour is fairly similiar to Xterm. That is, I get the following results (using the same number of iterations as you): Width | Time 1 | 87s 1000 | 34s 10000 | 34s I'm not absolutely sure why Konsole under KDE 4 is noticeably slower when width = 1, but I do know that the way that Konsole scrolls the screen up when adding a new line is very inefficient, which may well have something to do with it.