Version: (using KDE KDE 3.5.7) Installed from: Debian testing/unstable Packages Compiler: gcc 4.2.1 OS: Linux Maximizing / restoring is extremely slow for konsole --real-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 a compositing WM running or not.
I experience the same thing with gentoo and X.Org 7.3 - KDE version 3.5.7 This is from the X.Org log: > mieqEnequeue: out-of-order valuator event; dropping. > tossed event which came in late Not sure if this is related, this is new with X.Org 7.3 though. I can't remember having this problem with X.Org 7.2.
I am not able to reproduce this here, so I believe it is specific to a particular X.org setup or driver/video card combination. Either way, I'm afraid that --real-transparency is an experimental feature in KDE 3 and is not something that I can support. If you have the same problem in KDE 4 with --enable-transparency then that is a different story.
i can confirm the issue ( xorg 7.3, nvidia drivers, compiz-fusion ). takes about 5 sec on a 2GHz Athlon and it's interesting that it actually doesn't matter if i have compiz running or not using composite at all. there seem to be more issues with --real-transparency, for example the cursor vanishes when i start typing.
Same issues here, KDE4-SVN (13 march 2008). I have X.Org X Server 1.4.0.90 (Release Date: 5 September 2007) and nvidia-drivers-169.12.
As per comment #4, reopened.
> As per comment #4, reopened. The --real-transparency flag in Konsole (KDE 3) is experimental and there is not a lot I can do about problems with it. If you have a problem in KDE 4, where transparency is a supported feature, then please open a separate report.
Oops, rather silly of me to presume they share the same code.