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).
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?
I have nvidia-drivers-173.14.05 and this problem is still present.
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.
> 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.
*** Bug 163426 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
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.
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 ?
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.
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)
*** Bug 167476 has been marked as a duplicate of this bug. ***
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.
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.)
The problem seemed to be gone here too.
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
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..
@Ionut: For me (8400GT) it was the 180.18 driver (the beta) that fixed my problems. With the 177.XX I still had them.
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.
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
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
http://www.nvnews.net/vbulletin/showthread.php?t=125111 Some people say it's actually a bug in Qt.
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.
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.
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
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
can you try new nvidia 180.35 driver: http://www.nvnews.net/vbulletin/showthread.php?t=128939
(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.
(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.
Well.. what can I say.. now it works perfectly on NVidia and I haven't done anything...
It's gone after upgrade to KDE 4.2.1 (debian experimental) and NVidia drivers 180.35.
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)
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
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.
> 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.
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.
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
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.
Fixed with nvidia driver 275.09.04
*** Bug 278750 has been marked as a duplicate of this bug. ***
*** Bug 227246 has been marked as a duplicate of this bug. ***
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.
*** Bug 275101 has been marked as a duplicate of this bug. ***
*** Bug 245087 has been marked as a duplicate of this bug. ***
*** Bug 270308 has been marked as a duplicate of this bug. ***
*** Bug 282649 has been marked as a duplicate of this bug. ***
The slowness and freezing should have been fixed since nvidia driver 275.09.04 .