Slow text rendering in KDE's konsole not in xterm [SOLVED]

Message

heedless · Post by **heedless** » Sun Apr 20, 2008 10:15 pm

Hi,

I'm experiencing slow text rendering in KDE's konsole terminal

This is the test i'm running:

In Konsole:

time cat world.log
.
.
.
real    0m12.460s
user    0m0.002s
sys     0m0.042s

Same thing in xterm:

Code: Select all

real    0m3.831s
user    0m0.000s
sys     0m0.056s

I have a GeForce4 440 Go, using x11-drivers/nvidia-drivers-96.43.05.
RenderAccel is enabled:

Code: Select all

(**) NVIDIA(0): Option "RenderAccel" "True"
(**) NVIDIA(0): Enabling RENDER acceleration
(II) Initializing built-in extension RENDER

X.org:

Code: Select all

X.Org X Server 1.4.0.90
Release Date: 5 September 2007

I'm using a .fonts.conf file in my home directory:

Code: Select all

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
 <match target="font" >
  <edit mode="assign" name="rgba" >
   <const>none</const>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="hinting" >
   <bool>true</bool>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="hintstyle" >
   <const>hintmedium</const>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="antialias" >
   <bool>true</bool>
  </edit>
 </match>
</fontconfig>

The fact that x-term works fine, seems to indicate a KDE problem... however, it's worth noting that it seems like xterm's fonts are not as nice as konsole's (different font... or different hinting..).

Has anyone solved a similar problem?
Any Ideas?

i92guboj · Post by **i92guboj** » Sun Apr 20, 2008 10:37 pm

I once had a similar problem. It turned out to be a problem with the crystal decoration I was using (for some reason, it slowed down the redraw of the whole interface, changing back to plastik solved it).

I don't know if it's your problem, but It might worth a shot.

Also, depending on the antialiasing and if you have compositing enabled it could make a difference. Konsole is not the fastest term either..

heedless · Post by **heedless** » Sun Apr 20, 2008 11:14 pm

Hey,

Thanks for your reply.

I don't think it's a decorations thing:
1. I'm using Plastik
2. xterm is very fast and uses the same decorations. (I'm running xterm from within KDE)

I'm also not using any compositing manager. However the composite extension is enabled... will try to disable it, and if it helps I'll post again to share.

i92guboj · Post by **i92guboj** » Sun Apr 20, 2008 11:23 pm

heedless wrote:Hey,

Thanks for your reply.

I don't think it's a decorations thing:
1. I'm using Plastik

Well, it was just an idea. That happened to me like two years ago. So it probably has been solved. But since the problem was similar, I told you just in case.

Code: Select all

2. xterm is very fast and uses the same decorations. (I'm running xterm from within KDE)

That problem only arose when using qt apps + the crystal deco. So, xterm was fine for me as well. But in konqueror or konsole I would get a very bad and slow scrolling.

But if you use plastik, then your problem is not the same. Well, I tried

heedless · Post by **heedless** » Sun Apr 20, 2008 11:48 pm

I can't seem to disable Composite. Even when I set

Code: Select all

Option "Composite" "disable"

Explicitly, I keep getting

(II) Initializing built-in extension COMPOSITE

in me /var/log/Xorg.0.log

In any case, I'm not using a composite manager.

fikiz · Post by **fikiz** » Mon Apr 21, 2008 9:12 am

exactly the same problem here. And while time passes, the slowness is getting worse.

I'm still unable to disable the composite extension. any ideas?

thanks.

heedless · Post by **heedless** » Wed Apr 30, 2008 10:49 am

bump.

I'm sure we're not the ONLY ones to suffer from this.

Just as a side note, I'm running gentoo's "stable" branch - as in using ACCEPT_KEYWORDS="x86". problem still there.

I'm not completly sure wether it's just a KDE issue or an Nvidia thing.

I just tested this at work, running a Centos machine with a Nvidia Quadro FX 550..

I've generated a file like this:

Code: Select all

~$ perl -e 'for (1..2000000) { my $r = rand % 256; print "$r"; }' > /tmp/big.txt

and then ran:

Code: Select all

time cat /tmp/big.txt

on both terminals.

Konsole:

Code: Select all

real    0m10.703s
user    0m0.004s
sys     0m0.202s

Xterm:

Code: Select all

real    0m7.180s
user    0m0.002s
sys     0m0.169s

There's no big-difference... I might conclude that this is not a KDE problem, but on the other hand, why is it significantly faster using Xterm on my home computer?

Maybe Xterm is properly using the Render Acceleration feature? or maybe it has something to do with font Anti-Aliasing?

Maybe if someone else with a GF4 series card can confirm? or maybe, someone with a GF4 card and gnome can do the same test (using gnome terminal), to substantialize the case against KDE?

Thanks.

i92guboj · Post by **i92guboj** » Wed Apr 30, 2008 1:48 pm

If that's all the difference, there's nothing to worry about.

They are different terminals, with different configs, different font rendering engines and different resolution. Konsole is much heavier in absolute terms (though it stop being heavier when you have to open 20 terms, because konsole can wrap them into a single sessions, while xterm needs actually 20 terms open). The font rendering parameters, along with unicode support, antialiasing, and sync vs. async scroll are many parameters that greatly impact the speed of a terminal emulator. Try to configure them in a better way. The problem is -I think- that konsole is not very configurable, paradoxically.

There's absolutely no reason to think that that speed difference is indicative that something is wrong.

heedless · Post by **heedless** » Wed Apr 30, 2008 1:52 pm

i92guboj wrote:If that's all the difference, there's nothing to worry about.

They are different terminals, with different configs, different font rendering engines and different resolution. Konsole is much heavier in absolute terms (though it stop being heavier when you have to open 20 terms, because konsole can wrap them into a single sessions, while xterm needs actually 20 terms open). The font rendering parameters, along with unicode support, antialiasing, and sync vs. async scroll are many parameters that greatly impact the speed of a terminal emulator. Try to configure them in a better way. The problem is -I think- that konsole is not very configurable, paradoxically.

There's absolutely no reason to think that that speed difference is indicative that something is wrong.

There's no significant speed difference on my work machine - different hardware (different drivers too).
However, You should look at my first post for results from my home machine.

i92guboj · Post by **i92guboj** » Wed Apr 30, 2008 2:02 pm

heedless wrote:
i92guboj wrote:If that's all the difference, there's nothing to worry about.

They are different terminals, with different configs, different font rendering engines and different resolution. Konsole is much heavier in absolute terms (though it stop being heavier when you have to open 20 terms, because konsole can wrap them into a single sessions, while xterm needs actually 20 terms open). The font rendering parameters, along with unicode support, antialiasing, and sync vs. async scroll are many parameters that greatly impact the speed of a terminal emulator. Try to configure them in a better way. The problem is -I think- that konsole is not very configurable, paradoxically.

There's absolutely no reason to think that that speed difference is indicative that something is wrong.
There's no significant speed difference on my work machine - different hardware (different drivers too).
However, You should look at my first post for results from my home machine.

My guess is that on recent hardware, the limitations are not that evident, because it's fast anyway.

It's like all the fuss about the new baselayout + openrc thing: it might improve the boot times on a PII, but it's certainly non that noticeable on a +3000 mhz machine.

The same goes for graphics performance, which is what this is about.

Note that I am just speculating, not stating.

The best theory to see if my theory is correct or no, would be to see if there are some users with a GF4 video card that can do the same test. But, as I said, I don't see anything that odd on those timings: konsole was never the fastest.

heedless · Post by **heedless** » Wed Apr 30, 2008 2:06 pm

i92guboj wrote: My guess is that on recent hardware, the limitations are not that evident, because it's fast anyway.

It's like all the fuss about the new baselayout + openrc thing: it might improve the boot times on a PII, but it's certainly non that noticeable on a +3000 mhz machine.

The same goes for graphics performance, which is what this is about.

Note that I am just speculating, not stating.

The best theory to see if my theory is correct or no, would be to see if there are some users with a GF4 video card that can do the same test. But, as I said, I don't see anything that odd on those timings: konsole was never the fastest.

Well it used to be much faster... and besides, a 2.8GHz P4 with GF4 should be MORE than enough for simple scrolling text! (especially if that's all the computer was doing - and xterm is just as fast as my work machine!)

i92guboj · Post by **i92guboj** » Wed Apr 30, 2008 2:49 pm

A fast machine can't overcome a slow gpu only. The graphics drivers will ask the gpu (not the cpu) to do most of the work. If the gpu is slow, then it's slow and the rendering will be slow.

If it was faster before then it could be a driver issue, a regression in performance.

heedless · Post by **heedless** » Wed Apr 30, 2008 3:17 pm

i92guboj wrote:A fast machine can't overcome a slow gpu only. The graphics drivers will ask the gpu (not the cpu) to do most of the work. If the gpu is slow, then it's slow and the rendering will be slow.

If it was faster before then it could be a driver issue, a regression in performance.

Are you serious?
We're talking about scrolling text! that's such a simple task that my old mach-speed 2MB video card could do with no problem.

This gpu is good enough to play many games, it works perfectly in windows.

But suddenly - KDE's konsole is just too 'heavy' for this old hardware to handle?

This is most certainly NOT a slow hardware problem. and you're hindering the efforts of solving it by spreading these wrong ideas.

i92guboj · Post by **i92guboj** » Wed Apr 30, 2008 3:41 pm

heedless wrote:
i92guboj wrote:A fast machine can't overcome a slow gpu only. The graphics drivers will ask the gpu (not the cpu) to do most of the work. If the gpu is slow, then it's slow and the rendering will be slow.

If it was faster before then it could be a driver issue, a regression in performance.
Are you serious?

We're talking about scrolling text! that's such a simple task that my old mach-speed 2MB video card could do with no problem.

Yes. I am serious. And no, it's not just scrolling text. Anything under X, is, ultimately, a bitmap. It depends on the driver that you use and the graphics hardware (which is not necessarily a video card, but whatever that the driver is using to draw) . Even if it's scrolling text. If you don't believe me, just look at how nano performs when scrolling text under console (no X) if you have vesafb enabled. It's just awful.

This gpu is good enough to play many games, it works perfectly in windows.

Qt3, and hence, kde 3.x, makes NO USE AT ALL of opengl, as far as I know. So, you can't compare a game with the 3d extensions enabled, to the performance that you get in kde 3.x

But suddenly - KDE's konsole is just too 'heavy' for this old hardware to handle?

I didn't say that. Don't put word on my mouth. I said that it's heavier than xterm. I also said that is not the lightest thing in the world. I didn't say that your hardware can't handle it. That timings are not that bad for such a big file, and certainly, a good portion of the time is wasted doing I/O surely, not just drawing.

This is most certainly NOT a slow hardware problem. and you're hindering the efforts of solving it by spreading these wrong ideas.

I am out now. Luck.

pappy_mcfae · Post by **pappy_mcfae** » Wed Apr 30, 2008 7:01 pm

What kernel version are you using? If you are using anything in the .23 family or greater, you will get this problem. Try compiling your kernel with 2.6.22-gentoo-r10 or 2.6.22.29 version sources, and see what happens. I have an older Toshiba laptop that has sluggish updating in konsole, especially when I'm compiling something when I use any kernel version greater than 2.6.22.19. It seems slower machines are quite susceptible to this problem.

Good luck.

Blessed be!
Pappy

heedless · Post by **heedless** » Wed Apr 30, 2008 7:53 pm

pappy_mcfae wrote:What kernel version are you using? If you are using anything in the .23 family or greater, you will get this problem. Try compiling your kernel with 2.6.22-gentoo-r10 or 2.6.22.29 version sources, and see what happens. I have an older Toshiba laptop that has sluggish updating in konsole, especially when I'm compiling something when I use any kernel version greater than 2.6.22.19. It seems slower machines are quite susceptible to this problem.

Good luck.

Blessed be!
Pappy

Hey, thanks for your reply.
I'm using 2.6.24-gentoo-r5, but I'll give your idea a go (this *is* a toshiba laptop too).

I'll post later with results.

heedless · Post by **heedless** » Wed Apr 30, 2008 7:56 pm

If you could also post attach your kernel config file... specifially, AGP settings... DRI... anything that can effect graphics performance...
Would be a great help.

heedless · Post by **heedless** » Wed Apr 30, 2008 9:43 pm

pappy_mcfae wrote:What kernel version are you using? If you are using anything in the .23 family or greater, you will get this problem. Try compiling your kernel with 2.6.22-gentoo-r10 or 2.6.22.29 version sources, and see what happens. I have an older Toshiba laptop that has sluggish updating in konsole, especially when I'm compiling something when I use any kernel version greater than 2.6.22.19. It seems slower machines are quite susceptible to this problem.

Good luck.

Blessed be!
Pappy

I've emerged kernel-2.6.22-gentoo-r10, recompiled.. rebuilt my modules and...
It worked!
You were right!
Thank you!!!

Konsole:

Code: Select all

real    0m5.657s
user    0m0.002s
sys     0m0.047s

Xterm:

Code: Select all

real    0m5.324s
user    0m0.002s
sys     0m0.066s

Excellent!

So what does this mean? A kernel-bug? Driver Bug? ... probably.

Seems like my hardware is not that slow after all...

pappy_mcfae · Post by **pappy_mcfae** » Thu May 01, 2008 8:02 am

Sorry I took so long getting back. My alsa went belly up after I upgraded libmad.

Anyway, as to that bug, a lot of people are noticing it. Even this machine, a P4 Celeron M @ 1.86 GHz and 1 Gig RAM behaves that way when I use anything greater than 2.6.22.19, or its Gentoo analogue. The sad thing is, apparently the .22 kernel family is no longer in development. Frankly, that's ok with my systems because all the hardware is supported properly with the .22 kernels.

As far as my kernel goes, if you want to compare it, you can go here. Note that I use the libata drivers exclusively. Therefore, the boot drive is /dev/sda3 instead of /dev/hda3. I tell you that in case you want to compile my .config.

By the way, the Toshiba I have is a Satellite 1005-S157.

Blessed be!
Pappy

heedless · Post by **heedless** » Thu May 01, 2008 9:19 am

Thanks...
I got it working with no special config changes.

(Mine is a 1955-S807)

pappy_mcfae · Post by **pappy_mcfae** » Thu May 01, 2008 6:30 pm

You're welcome.

Blessed be!
Pappy

unull · Post by **unull** » Mon May 05, 2008 3:56 pm

I had similiar problems with painfull slow rendering in konsole.

I'm using the NVIDIA binary drivers on a Core2 Duo E6600. Disabling subpixel hinting in KDE's control panel did the trick for me.

heedless · Post by **heedless** » Mon May 05, 2008 4:21 pm

unull wrote:I had similiar problems with painfull slow rendering in konsole.

I'm using the NVIDIA binary drivers on a Core2 Duo E6600. Disabling subpixel hinting in KDE's control panel did the trick for me.

Probably a differe issue, disabling subpixel hinting was maybe the first thing I tried and it didn't help.