Version: unspecified (using KDE 4.5.2) OS: Linux Hello, I have open 70 application (KFontViewer) due to wrong manipulation. Under windows all work, under linux + kde plasma seam put X to 100%. I'm with proprietary driver for nvidia. Thanks to investigate to it. Reproducible: Always Steps to Reproduce: Open 70 font file with kfontviewer
If X is running at 100 % CPU, you should report this issue to the X developers at freedesktop.org.
I'm not sure, because it's kwin which flood X with draw/query.
- with or without compositing? - do you have a sysprof output?
with compositing how do sysprof output?
and without compositing? install sysprof && sysprof-module sudo modprobe sysprof-module sysprof press "run" (or play or whatever it's called) open 70x kfontviewer :: But better try w/o compositing first.
Bug created: https://bugs.freedesktop.org/show_bug.cgi?id=30777
Not freeze all kde without compositing, but heavy slow down. I'm setuping sysprof...
ok, before that: try with xrender compositing ... (i'm so mean ;-)
try with xrender compositing -> same that's without compositing but after few time kwin detect and disable compositing because it's slow... I show the task manager have difficult and freeze plasma, it's should have QTimer in single shot to render the task bar.
(In reply to comment #9) > I show the task manager have difficult and freeze plasma, it's should have > QTimer in single shot to render the task bar. I assume you wish a configurable / lower framerate on the taskbar ot least to collect entry changes -> that's a wish for the resp. product in plasma Now on the bug: a) That's no kwin bug for sure ;-) b) it's not like i could reproduce it (7600gt, 256.53, 512MB) but i run out of texture ram (black windows, kfontview opens @ 1283x420px and it's not the only stuff being opened) - i wonder whether you should encounter the same problem* c) i assume you won't get the problem by loading the windows delayed, ie. for ((i=0;i<70;++i)); do kfontview & sleep 1; done do you? Same goes when turning GL indirect: LIBGL_ALWAYS_INDIRECT=true kwin --replace & yesno? (you can spawn them undelayed) *for a non ARGB client like kfontview w/o alpha blending you'll need w*h*n*7/1024^2 MB memory - just for the flat X drawable and the gl texture, not caring about the client internal backingstore (7->10) or pixmaps allocated by the style/widgets/glyphs - this is btw. partially what would make the non gl case slow, the memory needs to be mapped into system RAM and from there to disk ... in doubt ;-) This way "xterm" would be a more relaxed testcase...
Created attachment 52476 [details] sysprof LIBGL_ALWAYS_INDIRECT=true kwin --replace & -> have crash kwin Now I'm in kernel gentoo 2.6.32 r19, it no freeze all plasma, but it's very slow. My target it's in all case, included the multiple application lunch, plasma desktop can't be freezed. I have 8GB of memory and swap disabled. You see the attached profile
well, sounds like it doesn't freeze anymore. the crash on indirect GL sounds weird, though does it happen immediately or only when opening many clients? the sysprof unfortunately contains _no_ details on the X11 process :-( i'm however pretty confident that it goes to the texture_from_pixmap conversion whereas XRender compositing is likely hit by some showup effect (zoom or so) this won't fix as long as we're doing fancy stuff on X11 and there's no EGL... screenupdates with many clients are still quite snappy here (render as well as gl), but since i encounter "out of TRAM" i'm pretty sure you're a) rendering indirect for some reason anyway (otherwise you'd have to get black pixmaps or est. 2gigs of VRAM) b) thus mapping into RAM, what is already slow. the only thing i could think of was the decoration impact - you'd have to try another one then. i still don't get the taskbar thing, doesn't seem to have much impact here =\ -> tell the plasma developers.
the crash on indirect GL sounds weird, though does it happen immediately or only when opening many clients? -> immediately I open all 70 application at better in 5min. 1) I have 8GB of memory + 512MB on graphic card 2) how correct it? This kind of bug will be fixed into next version? Same with other windows decoration B II preview, and I see decoration redrawer window by window.
there's no way to correct it. as for 512 MB of VRAM i can assure you're running out of it. If the windows don't turn black, you're mapping out to ram -> that is slow. > This kind of bug will be fixed into next version? It's rather unlikely a kwin "bug" or a bug at all, you might try with compiz (takes pretty much the same time here, though not 5 minutes at all...) but it's likely just "insufficient" hardware, sorry. (you might try to deactivate the shadow plugin, but it wouldn't have much impact on the oxygen decoration but only on B2, KDE2 etc.)
compiz not work here, it crash, then I have bad luke, :(
no offense, but this sounds like sth. is heavily misconfigured on your side... are you really sure that you're using the closed source nvidia driver and have glx & compositing enabled (which is the default since years) you might attach your /etc/X11/xorg.conf + /var/log/Xorg.0.log but i'm now quite sure that your issues have few to do with kwin...
Created attachment 52623 [details] log
I'm not offensed, ;) I have no too slow down with nouveau (open source nvidia drivers) and open source ati drivers. (instant open without any lag, grey part into the window during 3-8s kde disable composing) I have see lot of 3D effect with nvidia seam have global lock because the nvidia drivers work perfectly for game but have greate slow down as paralelle effect (like kwin do). I can do some test if it's for improve support to proprietary drivers performance and stability.
*** This bug has been marked as a duplicate of bug 197369 ***