Bug 83890 - Scrolling extremely slow when the windows contains broken lines
Summary: Scrolling extremely slow when the windows contains broken lines
Status: RESOLVED FIXED
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 1.3.1
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-23 19:20 UTC by gsasha
Modified: 2006-08-07 17:28 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
gsasha-1.vcf (185 bytes, text/x-vcard)
2005-09-30 19:10 UTC, gsasha
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gsasha 2004-06-23 19:20:50 UTC
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).
Comment 1 Lari Temmes 2005-09-26 22:49:15 UTC
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.

Comment 2 Kurt Hindenburg 2005-09-29 18:35:17 UTC
Could you try KDE 3.5?  I also would be interested in hearing if turning off the History helps/fixes these issues.
Comment 3 gsasha 2005-09-30 19:10:40 UTC
>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
Comment 4 Robert Knight 2006-08-07 17:28:30 UTC
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.