Bug 160467 - Slow maximize / restore for konsole --enable-transparency with NVidia GPU
Summary: Slow maximize / restore for konsole --enable-transparency with NVidia GPU
Status: RESOLVED UPSTREAM
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 2.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
: 163426 167476 227246 245087 270308 275101 278750 282649 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-04-06 13:03 UTC by Ionut Ciocirlan
Modified: 2011-12-06 17:35 UTC (History)
27 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ionut Ciocirlan 2008-04-06 13:03:59 UTC
Version:           2.0 (using KDE 4.0.3)
Installed from:    Gentoo Packages
Compiler:          gcc 4.2.3 
OS:                Linux

Maximizing / restoring is extremely slow for konsole --enable-transparency.

During maximization, X.org spikes with huge cpu usage (not noticeable during restore), and as far as i can tell, all video output is "frozen".
This is reproducible regardless of WM / compositing enabled or not.

Running xorg 1.4.0.90, with nvidia 169.12. One thing that might be of interest is exhibiting the exact same behaviour with konsole 1.6's experimental compositing support -- see bug #150287 for background.
The nvidia drivers where at the 100.x series back then (and iirc this started without a driver update), so the likely culprit must be a change in xorg 7.3. The 2nd comment in 150287 seems to confirm this.

Also, this doesn't seem to be a GPU issue, since the spike & freeze are less noticeable on a more powerful CPU (but they're still there).
Comment 1 Robert Knight 2008-06-02 08:10:44 UTC
Works well for me on my laptop with an Intel GPU.  I think this is a symptom of general problems with KDE 4, NVidia and KWin.  

Is this still present with the latest NVidia drivers?
Comment 2 Adrian 2008-06-12 01:20:33 UTC
I have nvidia-drivers-173.14.05 and this problem is still present.
Comment 3 marcela maslanova 2008-06-13 15:37:05 UTC
Could be slow changing of name in title bar or tabs be the same problem? After change of directory there are a few seconds name of the old directory.

Now I'm using konsole in Gnome (waiting for KDE4.1) Fedora-9. Maximalize is ok. I have laptop with Ati.
Comment 4 Robert Knight 2008-06-13 17:35:58 UTC
> Could be slow changing of name in title bar or tabs be the same problem?
 
No.  The delay in updating the tab titles is deliberately set to about 2 seconds after new input to the terminal.
Comment 5 Robert Knight 2008-06-14 22:11:34 UTC
*** Bug 163426 has been marked as a duplicate of this bug. ***
Comment 6 Bernhard Friedreich 2008-06-24 19:21:37 UTC
*** This bug has been confirmed by popular vote. ***
Comment 7 juanjux 2008-06-28 18:40:14 UTC
I've the same problem. I'm using 4.0.84 and Nvidia GPU too. I've noted a 0,5-2 seconds wait then I:

-Maximize or restore the konsole window.
-Call the "expose" effect when there is some konsole running
-Change desktop when the origin or destiny desktop is one containing a konsole

If I use Konsole from KDE3 (inside KDE4) all these problems dissapear.
Comment 8 Sandipan Mohanty 2008-07-21 11:31:10 UTC
I have faced all the problems mentioned by the other users here. I have Nvidia driver version 173.14.05. I am running 4.0.99. As suggested above, starting konsole with --notransparency option, or using kde3/konsole works. But I guess these are not long term solutions. KDE4 is the only desktop environment I use nowadays, but I have not noticed this behaviour in any other application. Is it really a generic KDE4+Nvidia issue ?   
Comment 9 David 2008-07-28 23:13:39 UTC
I can confirm this too with nvidia-drivers 173.14.09, xorg-server 1.3.0.0 and KDE from SVN trunk.
And in my special case, when the topic says "extremely" IS extremely: near 10 seconds or more with all KDE frozen while it is being resized.
Comment 10 Michael Harris 2008-07-30 17:50:11 UTC
I am having the same issue, with a delay of around 10 seconds when resizing. I also use compiz so I get round the problem by changing the resize window settings. If I add "class=Konsole" and change its resize mode (to anything other than normal) there is no delay.  And no need to use the --notransparency. 
I am using KDE4 packages from Debian experimental. (4.1)
Comment 11 Robert Knight 2008-09-22 03:54:04 UTC
*** Bug 167476 has been marked as a duplicate of this bug. ***
Comment 12 Teo Mrnjavac 2008-12-20 23:07:14 UTC
I can't reproduce this on both nvidia 8800GT and quadro nvs 140m, with proprietary drivers 180.16 and KDE 4.2 beta2. If others can confirm this has been fixed (either by KDE, Xorg or Nvidia), this bug may be closed.
Comment 13 juanjux 2008-12-20 23:18:41 UTC
I tried yesterday with Mandriva Cooker KDE 4.2 beta packages and NVidia 180.16 on a Sony Vaio with Nvidia 8400GT that had the problem with KDE 4.1 and Nvidia 177 drivers. The problem seemed to be gone here (I had other problems like crashing plasma, but this one not, desktop changes, maximizes and restores were lighting fast on the desktop having the konsole on it.)
Comment 14 BogDan Vatra 2008-12-20 23:57:04 UTC
The problem seemed to be gone here too.
Comment 15 Nadav Kavalerchik 2009-01-06 18:21:23 UTC
works very very well on >>
hp dv7 + debian sid 64bit + kde 4.1.86 
+ nvidia 9600M GT + nvidia 177.82 
+ Xorg 1.4.2

nvidia section from xorg.conf:

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
BusID           "PCI:1:0:0"
# compiz(fusion) recommands for nvidia
Option "RenderAccel" "True"
Option "AddARGBGLXVisuals"  "True"
Option "DamageEvents" "True"
Option "UseEvents" "False"
Option "TripleBuffer" "True"
Option "BackingStore" "True"
Option "NoLogo" "True"
#http://userbase.kde.org/GPU-Performance#NVIDIA
Option "UseCompositeWrapper" "True"
Option "AllowIndirectPixmaps" "True"
Option "PixmapCacheSize" "200000" 
Option "OnDemandVBlankInterrupts" "True" 
EndSection
Comment 16 Ionut Ciocirlan 2009-01-06 18:48:35 UTC
The last few posts suggest the problem is gone for GeForce 8 & 9, most probably because of the changes in 177.80: http://www.nvidia.com/object/linux_display_amd64_177.80.html
However on my Go 7900GS, it's just as bad as always. It does get fixed by using  InitialPixmapPlacement=2, but that's not an option given the funky artifacts and terrible slowness of various apps..
Comment 17 juanjux 2009-01-06 19:05:14 UTC
@Ionut:

For me (8400GT) it was the 180.18 driver (the beta) that fixed my problems. With the 177.XX I still had them. 
Comment 18 Ionut Ciocirlan 2009-01-10 02:57:07 UTC
I installed the 180.18 beta, and it's still dreadful on my 7900. This explains why: http://www.nvnews.net/vbulletin/showthread.php?t=118088 -- InitialPixmapPlacement=2 is set to be the default, but not for series 6/7 GPUs (yet?).

It's true that with this driver and IPP=2 I haven't noticed any obvious artifacts (e.g. the launcher and krunner search boxes turning black/striped), but it still makes scrolling in some apps a painful experience.

Anyway, I see zander's second post in that thread as an acknowledgement that it's nVidia's bug, so maybe this should be closed upstream. Moreso since series 8+ owners will probably be out in the clear at the next stable, while the rest could use IPP=2 and direct their bug reports at the affected apps. 

Immediate update: after digging for this url, I noticed they launched the new stable, which
- "Enabled the glyph cache by default and extended its support to all supported GPUs", and
- "Improved X pixmap placement on GeForce 8 series and later GPUs"

I'll report back if this one makes any difference.
Comment 19 Georg Wittenburg 2009-01-10 12:26:02 UTC
Works for me: nVidia GeForce 8600M GS, Linux 2.6.26,  X.org 7.3, nVidia 177.82, KDE 4.1.96.

Option  "UseCompositeWrapper"           "true"                       
Option  "BackingStore"                  "true"  # not documented     
Option  "OnDemandVBlankInterrupts"      "true"                       
Option  "PixmapCacheSize"               "3000000"
Option  "AllowSHMPixmaps"               "false"
[possibly some of these are not actually required]

$nvidia-settings -a GlyphCache=1 -a InitialPixmapPlacement=2
Comment 20 Vsevolod Krishchenko 2009-02-14 02:00:39 UTC
Still slow in KDE 4.2. No problem with other applications.

Debian experimental.

NVidia driver 177.82
X.Org X Server 1.4.2
Qt 4.4.3 
amd64
Comment 21 Artem S. Tashkinov 2009-02-21 12:13:27 UTC
http://www.nvnews.net/vbulletin/showthread.php?t=125111

Some people say it's actually a bug in Qt.
Comment 22 Sean Harmer 2009-02-23 13:11:52 UTC
That thread is relating to some other problem.

This actual bug appears to be fixed now that the nvidia drivers accelerate ARGB visuals properly as of the 180.xx series. I would recommend closing it unless anyone still gets this even with the 180.xx stable drivers.
Comment 23 Ionut Ciocirlan 2009-02-23 14:27:17 UTC
See comment #18 -- it's not fixed for series 6/7.

But as I said there, if you read between the lines of that forum post, an nvidia engineer acknowledges it's their bug, so it could be closed upstream.

Although zander says in an update that various 6/7 problems are resolved (and indeed they were), this particular problem still exists. That is, unless you enable InitialPixmapPlacement=2 which has unfortunate side effects.
Comment 24 Roman 2009-03-06 17:01:57 UTC
Hi,
this bug is still presented in KDE 4.2.1 "release 103", SuSe 11.1, with NVidia 86000 GT, drivers version: 180.29_2.6.27.18_0.3-0.1.
However I'm not sure that particularly NVidia drivers are causing this problems. 

I've installed SuSe 11.1 also at home where I have 
http://www.intel.com/products/chipsets/gma900/index.htm on
http://www.intel.com/products/chipsets/915g/index.htm . After I updated from KDE 4.1.x to 4.2.x and X server to the last stable version this problem partly dissapeared. But scrolling in Konsole and with big web pages in the web broser (Konqueror, Firefox, Opera) is still slow.

Regards,
Roman
Comment 25 Roman 2009-03-06 18:30:06 UTC
Hm.. it se(In reply to comment #24)
> Hi,
> this bug is still presented in KDE 4.2.1 "release 103", SuSe 11.1, with NVidia
> 86000 GT, drivers version: 180.29_2.6.27.18_0.3-0.1.
> However I'm not sure that particularly NVidia drivers are causing this
> problems. 
> 
> I've installed SuSe 11.1 also at home where I have 
> http://www.intel.com/products/chipsets/gma900/index.htm on
> http://www.intel.com/products/chipsets/915g/index.htm . After I updated from
> KDE 4.1.x to 4.2.x and X server to the last stable version this problem partly
> dissapeared. But scrolling in Konsole and with big web pages in the web broser
> (Konqueror, Firefox, Opera) is still slow.
> 
> Regards,
> Roman

It seems indeed like a problem of Konsole of KDE 4.x. I've just tried Konsole of KDE 3.x everything worked MUCH MORE quicker. As it should be...

Regards,
Roman
Comment 26 Nadav Kavalerchik 2009-03-06 18:33:00 UTC
can you try new nvidia 180.35 driver:
http://www.nvnews.net/vbulletin/showthread.php?t=128939
Comment 27 Ionut Ciocirlan 2009-03-06 18:40:34 UTC
(In reply to comment #25)
> It seems indeed like a problem of Konsole of KDE 4.x. I've just tried Konsole
> of KDE 3.x everything worked MUCH MORE quicker. As it should be...

Roman, it's been in the old konsole as well - see bug #150287
Try konsole --real-transparency.
Comment 28 Roman 2009-03-06 23:55:35 UTC
(In reply to comment #26)
> can you try new nvidia 180.35 driver:
> http://www.nvnews.net/vbulletin/showthread.php?t=128939

Well.. no, when everything work (with Konsole of KDE 3.5.x) I don't want to play with video drivers.. especially after reading the following thread:
http://forums.opensuse.org/pre-release-beta/409114-no-kwin-effects-after-installing-nvidia-driver-180-35-a.html

Regards.
Comment 29 Roman 2009-03-07 18:15:14 UTC
Well.. what can I say.. now it works perfectly on NVidia and I haven't done anything...
Comment 30 Vsevolod Krishchenko 2009-03-07 22:31:49 UTC
It's gone after upgrade to KDE 4.2.1 (debian experimental) and NVidia drivers 180.35.
Comment 31 Alex Frolov 2009-07-02 11:24:51 UTC
Experiencing deadly slow resizing of Konsole with transparent background.
Window manager freezes for at least 20 seconds.

- Konsole 2.2.3
- KDE 4.2.3
- Linux (x86_64) release 2.6.27.24-170.2.68.fc10.x86_64
- kmod-nvidia-2.6.27.24-170.2.68.fc10.x86_64-180.51-1.fc10.5.x86_64
- nVidia Corporation NV44 [GeForce 6200 LE] (rev a1)
Comment 32 Alin M Elena 2009-07-29 15:08:56 UTC
kde 4.3rc3 nvidia GeForce 8400M GS/PCI/SSE2
  Driver:   3.0.0 NVIDIA 185.18.14
opensuse 11.1 up to date.

with desktop effects effects on  the slowness is random but when you minimize to taskbar you can see the semitrasparent konsole frozen on dektop. at restoring it from taskbar is slow too but only somtimes you can see the semitransparent version for short time.

with desktop effects of the issue is more serious at restoring from taskbar, very slow and you can see redrawing artifacts.

Alin
Comment 33 Alexander 2009-08-27 11:10:11 UTC
Hi!

I use KDE 4.3 from debian unstable with latest nvidia driver 185.18.36, konsole very slow on repaint any contents in it, even without desktop effects.
Comment 34 Anton Petrusevich 2009-09-03 21:28:41 UTC
> I use KDE 4.3 from debian unstable with latest nvidia driver 185.18.36, konsole
very slow on repaint any contents in it. 

I second that. 4.3.0 or 4.3.1 -- doesn't mater. I don't know what exactly happened, previous reboot was a month or more ago and before that everything (kde 4.3.0, debian sid) was fine. Upgraded kde to 4.3.1, qt to 4.5.2-2 -- no luck. I have to use gnome-terminal for now.
Comment 35 Anton Petrusevich 2009-09-21 00:50:37 UTC
I wanna add some info. When I change konsole font from "Terminus" to another, then everything is ok, when I restore it back to Terminus, then Xorg eats 60% CPU.
Comment 36 Gabi Sarkis 2010-08-13 16:08:41 UTC
Same problem as #35, resizing is only slow when using the Terminus font, regardless whether compositing is enabled or not.

Gentoo.
NVidia GeForce 210
Twinview
nvidia-drivers 195.36.24
Linux 2.6.31 x86_64
KDE 4.4.5
Konsole 2.4.5
Comment 37 Marius Bjørnstad 2010-12-09 21:03:25 UTC
Same problem here, I am using the Monospace font.

Problem only occurs with many open terminals ~10, or when using a high-resolution external monitor (1920x1200). 

To reproduce reliably: open 12 konsole windows, then close them. Resizing is not slow. Then open 12 new konsole windows. Resizing locks the screen for ~ 5 seconds.

NVidia NVS 3100 256 MB
Laptop screen @ 1440x900 or external monitor DisplayPort->DVI @ 1920x1200
Driver version 260.19.21
Linux 2.6.35-22-generic x86_64
KDE 4.5.1
Konsole 2.5

The scenario for reproducing is not necessary to see the bug in general, and it occurs very often in daily use.
Comment 38 Alessandro Nakamuta 2011-06-06 20:47:09 UTC
Fixed with nvidia driver 275.09.04
Comment 39 Christoph Feck 2011-07-29 11:43:50 UTC
*** Bug 278750 has been marked as a duplicate of this bug. ***
Comment 40 Christoph Feck 2011-07-29 11:44:33 UTC
*** Bug 227246 has been marked as a duplicate of this bug. ***
Comment 41 o.colluphid 2011-07-29 18:51:04 UTC
While this bug may indeed be related to my problem, in my case it is not just a matter of slowing the system down with an eventual full or partial recovery, the system remains frozen solid no matter how long I wait. When first encountered I waited for several hours before doing a hardware reset and my system was still completely frozen, I could not reach a console or restart X with Ctrl Alt Backspace let alone view any system monitors. Perhaps the best clue I was able to provide may be that I got the same results after switching from Konsole to gnome-terminal but don't seem to have the problem with any other application.
Comment 42 Jekyll Wu 2011-07-30 13:01:31 UTC
*** Bug 275101 has been marked as a duplicate of this bug. ***
Comment 43 Jekyll Wu 2011-07-31 12:53:02 UTC
*** Bug 245087 has been marked as a duplicate of this bug. ***
Comment 44 Jekyll Wu 2011-08-16 13:03:25 UTC
*** Bug 270308 has been marked as a duplicate of this bug. ***
Comment 45 Jekyll Wu 2011-09-28 10:57:02 UTC
*** Bug 282649 has been marked as a duplicate of this bug. ***
Comment 46 Jekyll Wu 2011-12-06 16:19:34 UTC
The slowness and freezing should have been fixed since nvidia driver 275.09.04 .