Version: (using KDE 4.2.2) OS: Linux Installed from: Ubuntu Packages Clicking on system tray takes atleast 5 or more seconds to register. The perception you get is that kde has hung. Its annoying because you try to click it again and the result of it is that the application restores and minimizes again. Thanks.
Which application icon are you clicking to show/hide ? Or are you doing a different action in the system tray ? Thanks
It should be taskbar and not system bar but since I had written system bar I tried on that too and it too has the same problem. In the taskbar I just click the application's name on the taskbar.
Do you also experience this slowness when maximizing/restoring some windows ? What is your graphics card/drivers / X.org server. Do you use effect compositing? This looks KWin (the windows manager) related. Thanks
Yes I experience when max/restoring but I am not sure whether its a effect or a genuine problem :). Graphics card is a ati radeon hd4670 with fglrx and xorg at 1.6.0 version 11 revision 0. I am using compiz. How can i be sure whether I am using it?
Compiz -> Desktop Effects (KDE unrelated) Can you run "kwin --replace" on Konsole ? THis will close Compiz and start the default KDE Windows Manager. If you can't reproduce this slowness when using KWin, then, your issue is related to Compiz and this report can be closed. If you are still experiencing the slowness with KWin I'm going to reassign this to its developers Thanks
Wow. Its more worse now. I can clearly see the slowness.
I guess it may be related to some slowness of Qt and some graphics drivers. When do you starting to suffer this issue ? Thanks
Graphics driver I am not so sure because the problem started happening after I upgraded to jaunty. Previously I kde was running fine atleast in speed and this is the first time i am experiencing slowness. I had slowness in the previous versions too but it seems to have been fixed in the present version and now its the problem with the taskbar.
I think thats another bug. The panel does not seem to revert back to Oxygen theme which I had selected previously. Now reselecting Oxygen theme seems to set the color of the panel to the background of the desktop.
(In reply to comment #9) > I think thats another bug. The panel does not seem to revert back to Oxygen > theme which I had selected previously. Now reselecting Oxygen theme seems to > set the color of the panel to the background of the desktop. Yes, report this in another bug report. (politic is "one report per issue")
To summarize: * you have performance problems with both KWin and Compiz * you have performance problems since upgrade to Jaunty * there are many performance problems listed in Jaunty's Ubuntu and Kubuntu release notes for different hardware. => this looks like an Upstream bug. But to be sure: what's your graphics card and driver version?
(In reply to comment #11) > To summarize: > * you have performance problems with both KWin and Compiz > * you have performance problems since upgrade to Jaunty > * there are many performance problems listed in Jaunty's Ubuntu and Kubuntu > release notes for different hardware. > > => this looks like an Upstream bug. But to be sure: what's your graphics card > and driver version? I have a ati radeon hd4670 with amd catalyst showing my 2d driver as 8.60.40. I had performance problems with intrepid but it looks fixed in jaunty and looks very good. Now I have problems with slow mouse click event registering.
(In reply to comment #12) > (In reply to comment #11) > > To summarize: > > * you have performance problems with both KWin and Compiz > > * you have performance problems since upgrade to Jaunty > > * there are many performance problems listed in Jaunty's Ubuntu and Kubuntu > > release notes for different hardware. > > > > => this looks like an Upstream bug. But to be sure: what's your graphics card > > and driver version? > > I have a ati radeon hd4670 with amd catalyst showing my 2d driver as 8.60.40. > I had performance problems with intrepid but it looks fixed in jaunty and looks > very good. Now I have problems with slow mouse click event registering. (In reply to comment #11) > To summarize: > * you have performance problems with both KWin and Compiz > * you have performance problems since upgrade to Jaunty > * there are many performance problems listed in Jaunty's Ubuntu and Kubuntu > release notes for different hardware. > > => this looks like an Upstream bug. But to be sure: what's your graphics card > and driver version? Also when you mean by Upstream bug it mean kde itself or is there an upstream for kde also? Also what would be the upstream?
> Also what would be the upstream? ;-P great source of confusion due to arbitrary usage: http://en.wikipedia.org/wiki/Upstream_(software_development) he (likely) means: "probably ubuntu's fault" (though i thought the known issues focus on intel & uxa/exa) how's speed on the xrender backend (only kwin) and what's the (uncomposited) glxgears output? does /var/log/Xorg.0.log contain (m)any "EE" "WW" notes? (e.g. due module loading failures)
Created attachment 33298 [details] Xorg.0.log file. Xorg.0.log file for debugging.
(In reply to comment #14) > > Also what would be the upstream? > > ;-P > great source of confusion due to arbitrary usage: > http://en.wikipedia.org/wiki/Upstream_(software_development) > > he (likely) means: "probably ubuntu's fault" (though i thought the known issues > focus on intel & uxa/exa) Please correct me if I am wrong but shouldn't ubuntu be downstream? > > how's speed on the xrender backend (only kwin) and what's the (uncomposited) > glxgears output? > does /var/log/Xorg.0.log contain (m)any "EE" "WW" notes? (e.g. due module > loading failures) I don't know how to run an uncomposited fgl_glxgears. Should I do a kwin -- replace for that? fgl_glxgears output : Using GLX_SGIX_pbuffer 11074 frames in 5.0 seconds = 2214.800 FPS 12741 frames in 5.0 seconds = 2548.200 FPS 12690 frames in 5.0 seconds = 2538.000 FPS I have attached the Xorg.og.log file as an attachment in the previous post. Also if this might help: I am running it on a quad core Q8200 @ 2.33 ghz proc with 3 gigs of DDR2 ram and my graphics card has 512mb DDR3 ram. Thanks.
> Please correct me if I am wrong but shouldn't ubuntu be downstream? to e.g. KDE (deveolopers): yes, but e.g. not to their users. on the other hand tagging e.g. ati as KDE upstream is at least debatable as well (as aliasing upstream="relies on, links" can easily lead to circular streams, + KDE [upstream] DELL [upstream] Microsoft ... :-\ ) i have however (recently more often) heard it as synonym for SEP ("someone else's problem") - that's why i called it source of confusion... %) > I don't know how to run an uncomposited fgl_glxgears. Should I do a kwin -- > replace for that? just press "alt+shift+f12" > fgl_glxgears output : err, is that some special ati stuff? no normal glxgears? however, this > Using GLX_SGIX_pbuffer > 11074 frames in 5.0 seconds = 2214.800 FPS > 12741 frames in 5.0 seconds = 2548.200 FPS > 12690 frames in 5.0 seconds = 2538.000 FPS should be sufficient > I have attached the Xorg.og.log file as an attachment in the previous post. no really offending statements spotted stupid questions: - is compositing slow in general, or just "click some taskbar entry - delay - - - delay more - - - window opens at normal speed"? - what about minimizing a window? is that slow as well? - is starting e.g. glxgears (or any /thin/ app) from a shell slow as well?
In case of maximize/restore too it is slow. Minimizing is normal. I did alt+f2 and ran kwin --replace and checked the speed. It has the same problem. I ran kwin fps performance from system settings -> display -> effects. When idle it shows as 100 and when I maximize and restore from taskbar or do a maximize/restore the number comes down to 33-34 and then jumps to 100 and when i do it rapidly it comes down to 16 and also freezes too. Btw the number means fps right? Why is it stuck at 100? Also glxgears output shows : Running synchronized to the vertical refresh. The framerate should be approximately 1/339225 the monitor refresh rate. 21757 frames in 5.0 seconds = 4351.377 FPS 19247 frames in 5.2 seconds = 3736.635 FPS with lot of flickers though because I turned off vsync. Turning on Vsync has really bad performance. Also normal ring switching for 10 secs shows the fps drop to 56fps on an avg even though its considerably more stressful than maximizing/restoring. Hope this helps. Thanks.
*alt+shift+f12* is supposed to toggle compositing by default (no need to restart kwin) anyway, this sounds like a problem with pixmap allocation. unfortunately i just figured out the amd/ati manpage is... err... "incomplete" but adding this Option "OffscreenPixmaps" "true" to [Section Screen] in /etc/X11/xorg.conf /might/ help you you will then have to restart X11, e.g. log out and press ctrl+alt+backspace (don't press it while typing on your super important article, if ubuntu didn't patch and setup X11 to prevent "error outside" issues, X11 will just restart and take all running apps with it, moving unsaved data to /dev/null.. ) the fps is btw, capped to the screens refresh rate on vsync, that's what vsync is about =D
(In reply to comment #19) > anyway, this sounds like a problem with pixmap allocation. > unfortunately i just figured out the amd/ati manpage is... err... "incomplete" > but adding this > > Option "OffscreenPixmaps" "true" > > to [Section Screen] in /etc/X11/xorg.conf /might/ help you Added and it still has the same problem. My OpenGL options in System Settings ->Desktop -> Advanced are : Compositing Type -> OpenGL OpenGL Mode -> Texture from Pixmap. Texture Filter -> Trilinear Enable Direct Rendering -> Checked. Use VSync -> Checked. SmoothScaling -> Checked. Does it have anything to do with full screen rewriting? Are there any tests to check a full screen rewrite/refresh and check the performance? Thanks.
ok, you should first remove that statement from xorg.conf again. then you might test the XRender backend (i asked that some comments ago...) to figure if it's about the GL subsystem (or rather kwin, x11, ...) also using shared memory (though usually the deferred way on dedicated gpus) might help you (this is about how the window content is converted into GL textures) i doubt that the texture filter, direct rendering or vsync have any impact on this particular issue. smooth scaling is for x render only (though it works fine with recent nvidia drivers it may be a major performance hit when scaling windows, so to be sure, just turn it off before testing xrender)
Correct me if I am wrong but(In reply to comment #21) > ok, you should first remove that statement from xorg.conf again. > > then you might > > test the XRender backend > (i asked that some comments ago...) to figure if it's about the GL subsystem > (or rather kwin, x11, ...) I am not sure whether I understand this but am I not testing xrender backend when I am just running normally? Isn't the rendering delegation go like this KDE->X->GL->Hardware? Also all the anti aliasing logic or alpha compositing etc run by the hardware itself right? If no then how should I test the Xrender backend? Also now since DRI is enabled does it go KDE->GL->hardware bypassing X?
There are two possible backends for Compositing: OpenGL (default) and XRender. You can switch via systemsettings -> desktop -> desktop effects -> advanced tab.
I went changed it accordingly to XRender as you have mentioned,removed OffscreenPixMaps line in xorg.conf, rebooted and checked and I have the same problem. My fgl_glxgears output when XRender is enabled : Using GLX_SGIX_pbuffer 11297 frames in 5.0 seconds = 2259.400 FPS 12657 frames in 5.0 seconds = 2531.400 FPS Not sure that would help as it uses gl anyways.
the GL speed is not your problem (and glxgears fps it's expected to drop on a composited desktop) let me re-summon (an please correct any errors): - windows (of already running) apps show up delayed when you open them from taskbar or systray - happens with GL/Xrender composition - happens with KWin/Compiz - composite FX speed is ok for other cases (minimize animation, cover flow window switching, exposé - aka present windows, spaces - aka desktop grid) (and in particular, as i'm not sure on this from the above) - running a (thin, say xterm) application from a shell like konsole/xterm is delayed as well - the problem does /NOT/ show up on an uncomposited desktop so, instructions ;-) - suspend compositing (press alt+shif+f12, shadows disappear) - press a taskbar button -> result? - open an xterm (really "xterm", most rock solid fallback solution ever =) - resume compositing: (press alt+shif+f12 again, shadows reappear) - focus the xterm, enter "xterm" and press enter -> result (another xterm shows up, but does it take long?)
Pressing alt_shift+f12 does not seem to work. Anyways I think i could isolate it some more. I did a kwin --replace. Tried clicking some systray icons and the animation was very slow. Then went to system settings->desktop->Desktop effects and unchecked desktop effects. Now it is very fast. Clicking gives instantenous results. Opened xterm and is fast Went back again and enabled desktop effects and entered xterm. Cannot make out much whether it is effects or a bug. Next did compiz --replace. Opened up xterm and still cannot make out whether its slow. Opened up quite instantly I feel. You missed out maximize/restore button(Next to close button). Pressing that also is slow. Let me know if I am doing anything wrong.
Even in intrepid the speed was horrible. I think now after i did a kwin --replace i find it worse than intrepid. What could be the reason? All the other stuff seems to be fluid except this. Are you guys doing anything different on restoring?
Perhaps bug #177985? I have never been able to reproduce it, but it seems that there can be a problem when using Minimize or MagicLamp effect in combination with systray. Can you try to disable those effects?
Disabled minimize animation. Still the same problem. (Did kwin --replace first. With compiz I don't have any animations for minimizing/maximizing).
Whoa that bug id is nasty! It used to happen before(on interpid) where one of my cores was always going at 100% with X taking most of it and the answer I usually got from irc was "ati drivers sucks". I had disabled effects afterwards. Looks dangerous if you have overclocked your gpu. Are there any gui automation tools to select the combination of these effects and get the benchmarks? Triggering these problems are quite tedious.
well, they do. nevertheless, do i understand comment #26 right in that: opening an xterm from within another xterm is fast, just restoring it from e.g. the taskbar is delayed (and i mean /delayed/ the animation itself (if any, like zoom or so) is still smooth? could you in this case please try: - run amarok. (it's working with some other apps, e.g. kget) - close the window to the systray - enter a terminal (konsole, xterm) - call (w/o quotes) "qdbus org.kde.amarok /amarok/MainWindow show" after hitting enter, the amarok window will be opened. any delay?
Yes. Usually the minimize and animations associated with it is slow. I did it in two methods. Did kwin --replace, went to system settings and removed the effects and started amarok and then gave the command. It showed up instantenously. In fact very fast using xterm. For some reason doing a compiz --replace this time crashed the window manager. Just to be sure about the speed I redid the above step again. Next checked it on only kwin compositing and it was slow. Its took atleast 3 secs to pop out in konsole and i think 2.5 secs using xterm. Checked using compiz --replace and there too it was slow both in xterm and konsole.
ok, i think i misunderstood (comment #26): opening an xterm (from taskbar or launching a new app) is fast? does it just hang with Qt (and maybe GTK+) apps? please don't restart kwin everytime, that won't help you, so: keep effects activated (translucent windows/shadows etc) -> start an xterm (-> is there a delay?) -> start kcalc (-> is there a delay? - it won't come up as fast as the xterm, but that's normal) -> minimize the xterm (to taskbar), restore it (-> is there a delay?) -> minimize kcalc (to taskbar), restore it (-> is there a delay?) last: - change the window decoration (try plastik, NOT the UI style. kwin's deco: settings -> appearance -> windows)
Please reopen if this is still happening in KDE 5.