Bug 155174

For reference, this is my terminal size:

george@carbon ~ $ resize
COLUMNS=262;
LINES=109;

Created attachment 22865 [details]
Test bitmap font

This is the bitmap font I use with Konsole. Scalable fonts do not seem to
exhibit this regression.

I don't have a screen bit enough to fit that many columns and lines on at once.  230 columns x 75 lines is about the best I can do with a tiny font.

I wasn't able to reproduce the problem with a 230x75 display full of text and the MonoT bitmap font.  

Do you think you could try running Konsole with callgrind, switching between tabs a few times, then post the profile.

http://people.pwf.cam.ac.uk/gw280/konsole-profile/callgrind.out.{1719,1720}

This is the callgrind output from `valgrind --tool=callgrind konsole`. I started konsole, connected to irssi, created a new tab and switched between the two a few times.

Just to clarify your above comment, does the delay happen at all when using a scalable monospace font?  Is Qt built with optimisations enabled? (Performance should still be acceptable in debug builds, which I test with, but it can distort profiling results)

The delay is not present when using a scalable font.

My configure flags are:

./configure -qt-gif -no-exceptions -fast -prefix $QTDIR -nomake examples -nomake demos

This is Qt 4.3.3 without any third party patches.

KDE was built with:

cmake $SOURCE/$module -DCMAKE_INSTALL_PREFIX=$KDEDIR -DCMAKE_BUILD_TYPE=release

Hi George,

Does it make a difference what the content of the tabs is?  For example, is the problem evident when switching between tabs which only contain plain text with the default background color?

Konsole executes the same code path for bitmapped and scalable fonts, so I expect the problem is somewhere lower in the stack.  In which case the best thing would be for me to write a Qt-only testcase.

Some other information that might be useful:

1.  What graphics card and driver to you have?
2.  Is compositing enabled?
3.  Have you made any other changes to X.org as it came with Ubuntu (eg. enabled EXA instead of XAA).

Selecting large blocks of text on a new konsole tab also exhibits extreme slowness when using a bitmap font in comparison to a scalable font. This is without any background colours etc.

Graphics card is an nVIDIA GeForce 7600GS PCI-E with TwinView enabled (2xDVI outputs at 1600x1200 each) and (II) NVIDIA dlloader X Driver  169.07  Thu Dec 13 18:45:27 PST 2007

My xorg.conf is highly customised - will attach.

Created attachment 22887 [details]
xorg.conf

xorg.conf for the machine giving trouble.

I'm seeing the same slow speed as George, and I believe this is caused by the unlucky combination of Qt 4 and the proprietary nVidia drivers, which is known to cause severe slow down in various Qt drawing operations.

I've been rewriting Yakuake for KDE 4 these past two weeks (almost done) and can say the same about its opening animation, which is based on progressively adjusting the window mask to reveal a Konsole terminal display widget: While perfectly smooth in Xephyr's software implementation of XRender or with Intel drivers, it's quite a bit jerkier on my nVidia-powered main X server. Similarly, Yakuake keeps Konsole KParts in a widget stack and adjusts its custom tab bar painting in response to one of the terminals being raised, and this is just as slow as in Konsole on nVidia, while feeling instantaneous on Xephyr/Intel. 

I.e. I don't think Konsole is broken per se; it's something in nVidia's XRender acceleration infrastructure or Qt 4's painting system.

Others have noticed this as well: http://nowwhatthe.blogspot.com/2007/12/performance-and-qt-44-again.html

Hi Eike,

Obvious question, but have you tried with the latest NVidia drivers (as opposed to the stock ones which came with your distro)?

I'm using the 169.07 drivers on an 8800 GTX, yes. Those are the latest at this time. I tend to upgrade as nVidia publishes new beta and stable releases. 

The difference in Qt 4 painting performance between the nVidia-powered main X server and Xephyr, which uses a software-based XRender implementation and communicates with the host server via XShm and shadow framebuffer updates, is very pronounced in Konsole/Yakuake tab switching or window resizing or the Yakuake animation. Also, if you run applications with QT_X11_NO_XRENDER=1 on nVidia, the speed approaches Xephyr's (along with rendering errors from the lack of XRender support which are not present in Xephyr because it does use XRender). Which again leads me to believe that this is an nVidia or Qt4-on-nVidia issue.

Hello,

An updates on this with the latest NVidia drivers (169.12 at the time of writing)?

Sadly, no. I'm currently using 169.12 and Qt 4.4 Beta 1, and the performance issues with tab switching and Yakuake's animation when using a fixed-width bitmap font remain the same.

However, nVidia has issued[1] an new 171.06 Beta driver on March 7th. Quoting the announcement: 

"Note: This release has experimental support for a glyph cache on the GeForce 8 and 9 series that may improve anti-aliased font rendering performance. Enable with nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1."

The InitialPixmapProperty option of the driver controls where X pixmaps are created and held. The new driver supports a new value '2', which according to the headers is NV_CTRL_INITIAL_PIXMAP_PLACEMENT_VIDMEM, and that new GlyphCache option.

There's a 20+ page thread in then nVidia Linux driver forums[2] where KDE users have complained about shoddy rendering performance of anti-aliased text in KDE apps for years. It can be so bad with certain GPUs, I've seen videos where one can comfortably follow how individual lines in Kate are drawn. In general, it tends to be slower than pure VESA. This driver release appears to try and address that issue by trying harder to cache glyphs in video memory, avoiding costly roundtrips[3]. Reaction on the forums seems to be positive.

There's a number of parallels between the problem we're dealing with here and that story: Konsole, of course, deals in glyphs. Glyphs get drawn through XRender. The XRender software implementation (as used by Xephyr) being faster than the driver. And so on. Thus I'm hoping that this new beta driver might resolve this issue as well, but I haven't had a chance to test it yet unfortunately.

1 = http://www.nvnews.net/vbulletin/showthread.php?t=109422
2 = http://www.nvnews.net/vbulletin/showthread.php?t=65857
3 = http://www.nvnews.net/vbulletin/showthread.php?t=109478

http://www.nvnews.net/vbulletin/showthread.php?t=125111

It's not a KDE/Qt/Konsole/X11 bug.

*** Bug 207111 has been marked as a duplicate of this bug. ***

*** Bug 172250 has been marked as a duplicate of this bug. ***

Nvidia problem, nothing Konsole could do about it. A workaround is possible in Qt https://bugs.kde.org/show_bug.cgi?id=155174 .

Not sure that "Nvidia problem, nothing Konsole could do about it" is quite true.  I use Xfce Terminal on the same machine and it doesn't have this problem.

> Not sure that "Nvidia problem, nothing Konsole could do about it" 
> is quite true. 

Based on the report Lubos filed with Qt, a more accurate description if I understand correctly would be that when Konsole asks Qt to draw text using certain fonts, Qt is using a sequence of calls to the X server which are slow in the NVidia driver.

According to NVIDIA and my own quick test, this has been fixed in the latest beta driver:
http://www.nvnews.net/vbulletin/showthread.php?p=2149232

Hello George,

With regards to your recent blog post which has comments disabled - http://blog.gwright.org.uk/articles/2010/02/07/why-i-wont-use-kde-4

You may wish to try running Konsole with "-graphicssystem raster" which switches Qt to use its built-in software renderer for everything and which currently offers much better performance that X11 in many cases (though this is purely anecdotal, I don't know how well it stacks up across all the hardware and X.org versions available).

The other thing is that for monospaced bitmap fonts, I'm sure it would be possible to write a simple hack to render all the glyphs into a single pixmap and then just blit the appropriate part of the pixmap onto the terminal widget in the right place.  When it comes to rendering bitmap fonts consisting only of ASCII characters (perhaps with some extensions) then Qt's font rendering will no doubt go through many unnecessary hoops.  Something to consider if you ever find yourself bored with an hour to spare.

Robert - thanks for this. I've known that the X11 backend for Qt is buggy for quite some time, but forgot this. Anyway, I just tried with the raster graphicssystem and it's also taking nearly 2 minutes to complete on a full-screened Konsole session. Of interest though is that it took ~40 seconds on a window 1/3rd that size. This is on an intel integrated graphics chip (I think it's the 965).

I'd really love to help code and fix this (now that I have time after graduating) but I'm currently excluded from any open source development due to legal issues... I'll see what I can do.