Version: (using KDE 4.1.2) Compiler: gcc version 4.1.2 (Gentoo 4.1.2 p1.1) OS: Linux Installed from: Gentoo Packages When using regular console Vim from inside a konsole, many operations are very slow. For example, if I have a smallish (~1000 lines) file open, scrolling to the top with gg or scrolling to the bottom with G take virtually an eternity (500ms or more). The issue is the same with both compositing on and off, as well as with syntax highlighting in Vim on and off. I'm using a bitmap font (Fixed [Misc], size 11) rather than an antialiased font, so the rendering should be extremely fast. This problem does seem to be related to rendering speed though, the problem is exacerbated with a larger konsole, as well as (oddly enough) a larger file. CPU usage on X peaks close to 100% if you hold down the page up for page down keys in a large file, for example. I don't have this problem with a regular xterm in place of konsole, and this was never an issue in KDE 3.x.
Scrolling should be much smoother in KDE 4 than KDE 3 because there is a lot less redrawing going on. Indeed, that is what I experience. What graphics card and driver combination are you using? Is scrolling speed acceptable with truetype fonts (as opposed to bitmap fonts)?
I should clarify that scrolling in say, Konqueror is quite smooth and fast, even with smooth scrolling enabled. I've only seen the slowness problem in Konsole. I apparently don't have any antialiased fonts to pick from at the moment... I'll give that a try this afternoon when I have more time. This is with a Geforce 7950 GT and nvidia-drivers-177.70. I have most of the desktop effects enabled, and they're all very smooth as well.
Hi Neil, I think this may be a duplicate of http://bugs.kde.org/show_bug.cgi?id=155174, where the problem is specific to bitmap fonts and does not occur with scalable ones.
In my haste this morning, I didn't notice that the font selection select area was scrolled down initially, I saw the two empty spaces at the bottom as a cue that there weren't enough items in the select area to require scrolling. So it turns out I have a number of other fonts I can play with. Anyways... I tried a few other fonts, such as Bitstream Vera Sans Mono, and with "Smooth fonts" ticked, they are substantially faster than Fixed [Misc] (though still a lot slower than in KDE 3.x). However (and this seems quite odd to me, but it is indeed the case), if I tick "Smooth fonts" when using Fixed [Misc], the actual font appearance does not change whatsoever, but Fixed [Misc] becomes equally as fast as Bitstream Vera Sans Mono! To further confuse things, flipping the "Smooth fonts" switch for Bitstream Vera Sans Mono doesn't appear to have any tangible speed gain or loss. So, to summarize: +--------------+------------------+ | Smooth fonts | Non-Smooth fonts | +--------------------------+--------------+------------------+ | Bitstream Vera Sans Mono | fast | fast | | Fixed [Misc] | fast?! | slow | +--------------------------+--------------+------------------+ With the "fast" case being approximately the same fastness in all 3 cases, but still a lot slower than in KDE 3.x.
*** This bug has been confirmed by popular vote. ***
Hi Robert, Did you ever try watching aalib-based demos on kde4.x konsole ? I tried "aafire -driver curses" and it looks like there is a huge performance regression. On kde3 konsole the animation is smooth as butter but on konsole4 it's a pain to watch the demo. Setting "Smooth fonts" option on does make it better but still completely unacceptable. Ascii-art demos like aafire, bb, "mplayer -vo aa:driver=curses" are very well suited for terminal performance tests. It might make sense to use them as konsole benchmarks and for profiling sessions. -- Paul (BTW: konsole4 is the reason why i still prefer kde3 desktops, maybe i'm not the only one)
Hi Paul, I haven't seen aafire before, thanks for pointing it out. That demo doesn't run smoothly for me on any terminal (xterm, gnome-terminal or Konsole) once the fire fills the screen. xterm is the smoothest, as you'd expected because the text rendering is more simplistic. Konsole follows and gnome-terminal is the least smooth. What graphics card/driver combination are you using?
I did notice though that aafire (KDE 4.2, Qt 4.5 snapshot) ran noticeably faster with anti-aliasing on that with it off which is unexpected.
@Robert, >What graphics card/driver combination are you using? Geforce GT8800, nvidia-drivers-177.80 (x86-64) >aafire For me also Xterm is the smoothest, followed closely by konsole3, all others are far-off. How is text rendering done in konsole ? Are you using sprites of letters that get bitblt into the NxM raster of the terminal screen ?
> Geforce GT8800, nvidia-drivers-177.80 (x86-64) Historically NVidia's drivers have been very slow with KDE 4, slower than running the application through a driver (like nv or vesa) with no acceleration at all. I was under the impression that this is fixed with the latest drivers though. > Are you using sprites of letters that get bitblt into > the NxM raster of the terminal screen ? Text is divided into chunks of equally formatted characters and then dispatched to Qt to draw. Layout of the text and conversion to a series of glyphs to blit to the screen is handled by Qt - the exact path taken will depend on the platform and the current graphics engine. gnome-terminal and Konsole 3 work the same way. Konsole 4 is theoretically better because Konsole 3 dispatched characters to Qt one at a time for drawing whereas Konsole 4 sends text in batches divided up according to character formatting. The reason for not just storing one pixmap per ASCII character and then blitting that to the screen in the appropriate place is because Qt's text drawing provides comprehensive unicode support, anti-aliased glyphs and sub-pixel rendering - or in short, pretty text and funny languages. Of course, if you don't care about either of these then you're incurring overhead for something that is not being used - although the text engine in Qt should try to minimize the overhead in cases where you're drawing un-smoothed ASCII fixed-width text anyway. On my Intel hardware and even my very old Radeon M6 Konsole 4 is faster than Konsole 3 - mainly because of the above change in how characters are dispatched for drawing.
> blitting that to the screen in the appropriate place is because Qt's text > drawing provides comprehensive unicode support, anti-aliased glyphs and For Unicode that would be a HUGE sprite table :) I'd expect that somewhere down the graphics pipeline (konsole -> QT4 -> X11 -> Nvidia) some kind of caching for character-rendering happens anyway. > On my Intel hardware and even my very old Radeon M6 Konsole 4 is > faster than Konsole 3 - mainly because of the above change in how > characters are dispatched for drawing. On my System it's the other way around (konsole3 clearly outperforms konsole4) There is only _one_ explanation left: Some part of the NVidia driver must be seriously broken :(
> Some part of the NVidia driver must be seriously broken :( Or possibly that Qt is doing something which happens not to be fast with NVidia graphics. As I said, I was under the impression (from reading blogs on planet.kde.org and via emails) that this is fixed in the latest drivers. I'll need to ask another KDE dev who uses NVidia. I did spot some possible optimizations that could be done in Konsole that should improve performance a little on the aafire demo but nothing that would cause massive gains.
A dupe of bug 155174.
Still an issue in KDE 4.2 with Nvidia drivers 180.27.
Also with nvidia 185.18.36 (and KDE 4.3.1)
As a workaround for issues with particular graphics drivers, try running Konsole with software rendering using: konsole -graphicssystem raster
`konsole -graphicssystem raster` actually seems quite a bit slower than regular old konsole. This is with KDE 4.3.0 and nvidia 180.60 (185.* was causing frequent X crashes for me, though only with KDE 4).
(In reply to comment #16) > As a workaround for issues with particular graphics drivers, try running > Konsole with software rendering using: > > konsole -graphicssystem raster Yes, that did seem to make things much faster. Thanks!
> `konsole -graphicssystem raster` actually seems quite > a bit slower than regular old konsole. Just to clarify - by 'regular old konsole' are you referring to Konsole / KDE 4. In other words, if you run: konsole -graphicssystem native How does it compare with: konsole -graphicssystem raster What about other Qt/KDE applications (the -graphicssystem switch works with anything written in Qt 4)?
(In reply to comment #19) > > `konsole -graphicssystem raster` actually seems quite > > a bit slower than regular old konsole. > > Just to clarify - by 'regular old konsole' are you referring to Konsole / KDE > 4. In other words, if you run: > > konsole -graphicssystem native > > How does it compare with: > > konsole -graphicssystem raster > > What about other Qt/KDE applications (the -graphicssystem switch works with > anything written in Qt 4)? By regular old konsole I mean: konsole which appears to run at the same speed as konsole -graphicssystem native which is much slower than Konsole from KDE 3.x, but noticeable faster than konsole -graphicssystem raster I'll give the switch a try with some other apps, although I haven't noticed any other major rendering speed regressions as I've seen in konsole in KDE 4.0.
Neil - I presume you were using bitmap fonts in those tests? Can you check the difference gain with scalable fonts.
*** This bug has been marked as a duplicate of bug 155174 ***