Version: (using Devel) Compiler: gcc 4.3.3 OS: Linux Installed from: Compiled sources For some weeks kwin OpenGL rendering is unusual slow. Not only that the effects are stuttering very often, there is also a quite noticeable delay when rendering normal stuff like the maximize and minimize buttons. When I keep moving the mouse over these buttons (so that the images keeps changing) X cpu usage goes up to ~40% (and as mentioned they change with a visible delay). When using XRender this is much better (no delay and X cpu usage at ~3-5%). With this only fade and resize effects are slow sometimes. XRender effects were always kind of laggy but OpenGL used to be fast. Video card: GeForce 8600M GT (tried with 180.5x; 185.*) Driver: 185.18.04 Qt 4.5.1 (with qt-copy patches) xorg-server: 1.6.1 This problem definitely has something to do with kwin built from trunk. Installed kwin-4.2.2 (mixed it with my normal system which is quite unstable but it is able to do enough to compare the performance) and OpenGL performance there seems completely normal (X cpu usage at ~4%; effects very smooth).
which window decoration are you using. Oxygen/Ozone had a repaint bug. All unpatched forks cause lot of CPU usage.
Ozone. Didn't change the window decoration at all (except the stripes next to the title).
can you try with a different windeco? E.g. plastik?
same / similar problem with plastik. cpu usage: kwin-4.2.2: OGL: kwin = ~10%; X = ~5% kwin-9999: OGL: kwin = ~5%; X = ~34% <-- XRender: kwin = ~10%; X = ~7%
advanced settings: ----- OpenGL mode: "Texture From Pixmap" [x] Enable Direct Rendering [ ] Use VSync All Effects: ---- [ ] Blur improvements?
(In reply to comment #4) > same / similar problem with plastik. ok so it is not the problem with repaint bug. Thanks for testing > > cpu usage: > > kwin-4.2.2: > OGL: kwin = ~10%; X = ~5% > > kwin-9999: > OGL: kwin = ~5%; X = ~34% <-- > XRender: kwin = ~10%; X = ~7% What I think is interesting is the fact that the CPU usage of kwin is less. So from that point of view something became better. Are you using the same effects in 4.2 and 4.3? Perhaps it's possible to find an effect which is causing the trouble. And could you please try the show paint effect and have a look if something else is causing repaints? And for comparison: XRender in 4.2 :-)
(In reply to comment #5) > advanced settings: > ----- > OpenGL mode: "Texture From Pixmap" > [x] Enable Direct Rendering > [ ] Use VSync > > All Effects: > ---- > [ ] Blur > > improvements? I don't have blur enabled. Disabling vsync made no difference. btw. with plastik I wasn't able to see any significant drawing delay (but also high X cpu usage) which may be because of the fade effect of those title buttons instead of an instant change. cpu usage with kwin-4.2.2: XRender: kwin = ~5%; X = ~7% (and no visible delay when moving the mouse over the title buttons) Effects should be the same for kwin-4.2.2 and kwin-9999. Will try to set up a complete kde 4.2 environment with "fast kwin" so that I can configure and use kwin-4.2 easily and without problems. With this I will do those extended tests to see if I can find some special reason for this problem.
The problem is not caused by any plugin. Just disabled all and it was still present. Using Show Paint I don't see any redraw problems. This problem is also visible using Show FPS. While moving the mouse over those buttons with "9999" the fps drop to ~12. With 4.2.2 there is no real difference.
I'm experiencing the same issues with 4.3 Beta1. Everything is fast in 4.2 with the same Nvidia driver. If I turn on the paint plugin, I see constant red/pink flashes on the screen (every 1/10th of a second or more), it seems it's constantly repainting.
does repainting stop if you shutdown the desktop? kquitapp plasma-desktop
No it does not stop.
ok, i can reproduce it by activting the "slide back" plugin (i just activated all nonsense "look we're animated" effects, got it, deactivated one by one, slide back did it, reactivated all nonsense except the backslider, no problem activated slideback, recursive repaint again...
I can confirm that deactiving slide back stops the repainting. On the other hand, the general sluggishness of kwin compositing remains.
(In reply to comment #12) > ok, i can reproduce it by activting the > > "slide back" > > plugin (i just activated all nonsense "look we're animated" effects, got it, > deactivated one by one, slide back did it, reactivated all nonsense except the > backslider, no problem activated slideback, recursive repaint again... I can't see this repaints of the SlideBack effect here. Could you please give some more details about when this is happening. At best by opening a new Bug report because this one is about another issue. Please put me directly on CC. Thank you.
you can probably forget about this. though slideback seems to trigger sth., after actually using it (i.e. activating another window), the continuous repaints stop. there might be a general race condition on suspending/restarting the effects and slideback enters it (does not occur w/o using slide back), but it's (for me) no long time problem. as mentioned, i don't really use the effect and just entered it when testing clovis' report - sorry :-(
I confirm the same behaviour (smooth in 4.2 and sluggish in 4.3 beta) with an intel 945
I guess I should just add that I get this behaviour on an nvidia 8400GS, therefore I can't see it being driver related, even more so since the issue wasn't there in 4.2.
hmmm... 1. i tend to blame the ARGB deco support 2. interestingly effects stutter here whenever i change the active window (like on slide desktop, just click and move around,...) /iff/ (ie. and only if) i use a setup with deco borders (no matter which deco) i hate promoting myself but there's no "built in" deco with this ability: - can you try installing bespin - choose it's deco and set the size to tiny (you won't get any window border except the titlebar, you can still use alt+rmb to resize the window, or activate the resize grip provided by the deco) - see whether stutter's gone or diminished?
I've tried it with tiny bespin deco and indeed it feels more fluid altough the stuttering is not completely gone. Another thing. While debugging the SlideBack effect I've seen that the deco gets painted even if I mark its region not to be painted. I can't remember seeing this behaviour in 4.2.
You can test this without installing bespin by using the decorations context menu -> Advanced -> No Border Active it and you'll have perfectly smooth animations for this window.
Is this only with OpenGL or also with XRender? I think there is a repaint bug in the OpenGL part (e.g. look at the startup notification). And I think I know where, but if it is reproducable in XRender I'd look at the wrong part.
It's only OpenGL. XRender runs fine.
SVN commit 969215 by graesslin: Scene OpenGL paints window content only when mask does not contain PAINT_DECORATION_ONLY like XRender backend. This could be the solution to the performance regression when starting effects at activation change. CCBUG: 191694 M +6 -3 scene_opengl.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=969215
Result of investigation: the slow performance on change of activation is caused by a new texture from pixmap for the window decoration (line 1533ff in scene_opengl.cpp). This new tfp was added as there was a repaint problem (decoration of old focus did not get updated). I will try to change the code so that we don't need the tfp.
no notable improvement... notable - sorry :-( i.e. although there might have been a redundant tfp call, it didn't cause the lag (here) - using only the titlebar and no borders (therefore the clip isn't regarded at all) is still significantly smoother (though the titlebar area is probably bigger than the combined border areas) no deco is even faster. however: i set the updateDeco flag (:1459) to "false" and the lag is gone. as i don't notice any visual error, glitches etc. (the deco is properly updated on active change, including colors, gradients, text color...): what's this supposed to handle and is it maybe redundant on an active state change?
(In reply to comment #25) > however: i set the updateDeco flag (:1459) to "false" and the lag is gone. That's the result of my investigation. If it is false there is no lag (the previous commit was unrelated to the lag as I had to notice) > as i don't notice any visual error, glitches etc. (the deco is properly updated > on active change, including colors, gradients, text color...): what's this > supposed to handle and is it maybe redundant on an active state change? Well I have the problem that when I change active client that the decoration of the previous active client does not always get's updated. Noticable with oxygen deco and the blue stripes. I noticed that when I change client by clicking on the title bar everything is fine, but when clicking on the window content deco is not updated and show paint does not show paint for the decoration.
I actually see a little improvement after recompiling kdebase-workspace, but there's still some sluggishness, very visible at times with the sheet effect.
*** Bug 193074 has been marked as a duplicate of this bug. ***
some info to the repaint issue: I only see the repaint problem if paintSimpleScreen is used. If paintGenericScreen is used (that is transformations) everything is fine. So using presentwindows, desktopgrid or slideback I don't have the repaint problem. And I definately can say that the pixmap get's updated, it's just not painted. So I'll remove the code that causes the performance problem although it might cause repaint errors. It's just the wrong way to solve the issue.
i confirm the updated pixmap. when e.g. damaging some other area of the window (entering a WA_Hover enabled widget) the deco gets updated. also the problem does not only occur on window activation, but i could reproduce it quite easily (and prominent) when typing and (shortcut) saving in kwrite. the [modified] title extension runs behind the state. the problem should be in paintredirector.cpp. eg. commenting the timer call doesn't entirely break the deco painting. it still works in about 50% of all cases (no desktop, no overlapping windows, nothing else that could damage that area) so i'd almost say the whole thing just works "by accident" i assume the damage list gets extended in Client::repaintDecorationPending() when the damage event has been handled and the fun is over. it's then probably just handled on next damaging. i suspected the signal/slotting to be too slow for this purpose, BUT (in a q'n'd hack) calling the client to extend the damage list DIRECTLY did NOT help. i'll investigate later on as well, but now i need to paint a HUUUGE door, what's gonna last some hours ;-) oh, and just for the records: even with kwrite way i cannot reproduce the issue with the bespin deco. whatever this means... ;-P
SVN commit 969647 by graesslin: Do not release the bound pixmap every time the decoration get's updated. That is the reason why effects were slow when active client changed. Additional do a XSync when the decoration pixmap is painted. That ensures that the pixmap is painted before the texture from pixmap is done. BUG: 191694 M +2 -0 client.cpp M +1 -5 scene_opengl.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=969647
thx, at least it is fast again :)
I confirm. Thanks again!