Bug 155174 - Slow bitmap font renderig with nvidia driver
Summary: Slow bitmap font renderig with nvidia driver
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Konsole Developer
: 172250 207111 (view as bug list)
Depends on:
Reported: 2008-01-06 09:13 UTC by George Wright
Modified: 2010-02-09 01:44 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:

Test bitmap font (25.75 KB, application/octet-stream)
2008-01-06 09:29 UTC, George Wright
xorg.conf (2.28 KB, text/plain)
2008-01-07 08:18 UTC, George Wright

Note You need to log in before you can comment on or make changes to this bug.
Description George Wright 2008-01-06 09:13:46 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
OS:                Linux

I am using Konsole from tags/KDE/4.0.0 in the subversion repository.

I use large Konsole windows - maximised on my desktop at 1600x1200, with a 6px bitmap font. It appears that activities which update a large proportion of the viewport result in significant delay between the user input and any results coming out of Konsole.

For example, if I have two tabs open (one with irssi, one with some arbitrary other application is my most common use case) and switch to the other tab, I will notice a lag of ~1-2 seconds before the viewport is rerendered. In comparison, in Konsole 1.6.6 from KDE 3.5.7, it feels instant.

Similarly, highlighting large blocks of text results in significant delay between the action of highlighting with a mouse, and any selection appearing on screen.
Comment 1 George Wright 2008-01-06 09:21:22 UTC
For reference, this is my terminal size:

george@carbon ~ $ resize
Comment 2 George Wright 2008-01-06 09:29:00 UTC
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.
Comment 3 Robert Knight 2008-01-06 13:29:16 UTC
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.
Comment 4 George Wright 2008-01-06 18:50:23 UTC

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.
Comment 5 Robert Knight 2008-01-06 19:03:09 UTC
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)
Comment 6 George Wright 2008-01-06 19:11:21 UTC
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:

Comment 7 Robert Knight 2008-01-07 01:01:19 UTC
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).
Comment 8 George Wright 2008-01-07 08:17:04 UTC
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.
Comment 9 George Wright 2008-01-07 08:18:10 UTC
Created attachment 22887 [details]

xorg.conf for the machine giving trouble.
Comment 10 Eike Hein 2008-01-07 14:23:24 UTC
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

Comment 11 Robert Knight 2008-01-07 16:05:58 UTC
Hi Eike,

Obvious question, but have you tried with the latest NVidia drivers (as opposed to the stock ones which came with your distro)?
Comment 12 Eike Hein 2008-01-07 16:14:35 UTC
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.
Comment 13 Robert Knight 2008-03-17 18:38:06 UTC

An updates on this with the latest NVidia drivers (169.12 at the time of writing)?
Comment 14 Eike Hein 2008-03-17 18:51:00 UTC
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
Comment 15 Artem S. Tashkinov 2009-01-29 05:55:11 UTC

It's not a KDE/Qt/Konsole/X11 bug.
Comment 16 Thomas Zell 2009-09-12 10:49:29 UTC
*** Bug 207111 has been marked as a duplicate of this bug. ***
Comment 17 Lubos Lunak 2010-01-10 23:58:27 UTC
*** Bug 172250 has been marked as a duplicate of this bug. ***
Comment 18 Lubos Lunak 2010-01-11 00:00:48 UTC
Nvidia problem, nothing Konsole could do about it. A workaround is possible in Qt https://bugs.kde.org/show_bug.cgi?id=155174 .
Comment 19 David Rosenstrauch 2010-01-11 05:25:21 UTC
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.
Comment 20 Robert Knight 2010-01-11 10:55:40 UTC
> 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.
Comment 21 Thomas Zell 2010-01-16 16:43:28 UTC
According to NVIDIA and my own quick test, this has been fixed in the latest beta driver:
Comment 22 Robert Knight 2010-02-07 14:16:47 UTC
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.
Comment 23 George Wright 2010-02-07 16:02:51 UTC
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.