Bug 314532

Created attachment 76947 [details]
Screenshot of the performance overlay

The graph after launching krunner with <Alt><F2>...

please provide
qdbus org.kde.kwin /KWin supportInformation

in case the graphicssystem is set to native: don't.
use raster for aurorae or anything qml related.

Support information:
http://paste.kde.org/666356/

Created attachment 76956 [details]
Patch for main.qml

I did some testing and found out that the slowdown also appears if a windows is (de)activated with compositing but all effects off.
With the proposed changes performance is ok now , but I don't understand, why this has such an impact...

The only problem now is, that the decoration is black when the window is resized, but this might be a sepearte bug.

> Qt Graphics System: native

Because QML/QGraphicsScene *hates* the native graphicssystem.
"kcmshell4 kwincompositing", 3rd tab, select "raster" - be happy.
Animations will likely be in the cards as well.

Please confirm or deny that hypothesis, thanks.

instead of patching out all animations, it should be enough to do:
root.animationDuration = 0;

in the first of your changes. I'll think about whether it makes sense to detect the graphics system in Aurorae and disable the animations for native, but my feeling is that it's not worth it anymore given that native is dead in Qt 5.

Created attachment 76983 [details]
New patch

the patch looks reverted.

I'm not a fan of adding a config option as it doesn't solve the root problem. If we adjust it, it needs to be based on the used graphicssystem. The animations are not a problem on raster, just on native.

1.
Changing to "raster" did the trick, it works smoothly - but the perfomance graph suggests, that the animation still has a rather large impact - although not really noticeable in FPS / to the user 

2.
I created a new patch, that enables the user to set this animation on / off. Indeed setting animationDuration = 0 is enough (and works smoothly with native)

3.
>decoration is black on window resize
This magically solved itself... :)

4.
Another suggestion from my side:
Rename e.g. "Native" to "Native (X.org)" and "Raster" to "Raster (Qt internal)", because most users (and myself up to now) intuitively think, that "native" is better in performance than "raster" [which is wrong as I learned :) ] ...
... and honestly - up to now I didn't even notice the nice tooltip explaining this issue, although regularly checking for changes

>it's not worth it anymore given that native is dead in Qt 5.
If there are no real disadvantages, I would suggest a silent removal of the "native" option - or at least change the user settings to "raster" in one of the next KDE releases (is that possible via kconf_update?) - but that's not my business :D

Sorry for the wrong patch, usually svn or git do the job - bad luck trying to create one manually...
Btw.
topMargin: 3 makes the title bar text being vertically in the middle not sticking to the top, which looked kind of strange

>If we adjust it, it needs to be based on the used graphicssystem.
Can the defaults be set according to the graphicssystem?
For me the animation is almost not noticeable, so I would be glad to actually turn it off.

(In reply to comment #10)

> >it's not worth it anymore given that native is dead in Qt 5.
> If there are no real disadvantages
is, see comment about xrender in the "nice tooltip" :-)
This has to happen alongside a general "Qt does not support XRender and we have to do it all internal" change.

What was discussed was to bring in decos into defaulting the value, ie. if you changed to aurorae, you'd immediately get raster set (unless you force it back, of course)

> For me the animation is almost not noticeable, so I would be glad to
> actually turn it off.
as it actually affects all Aurorae themes I'll add a generic solution.
* if native is used, always disable all animations
* if raster is used have a config value
* default to animations: on

I also have big performance problems with the plastik theme since 4.10.0 but I am not using desktop effects.
It takes ~4 seconds (!) to update the window decoration (inactive->active) when switching to another window. This causes high cpu usage of kwin during that time.
I have a AMD Athlon Neo X2 Dual Core Processor L325 (1.5 GHz) with a Mobility Radeon HD 3200 Graphics (open source drivers).

May this be related or is it something different?

No, likely the same issue.
Ensure to use the raster graphicssystem and if performance is still low, switch to the "notebook" (or laptop?) decoration which is one of the remaining legacy decos.

Just noticed that I was using "native" as graphics system in kwin. When switching to "raster" it's a bit better but still much to slow. After enabling desktop effects (together with raster) it's acceptable.

see comment #7 and edit /usr/share/apps/kwin/decorations/kwin4_decoration_qml_plastik/contents/ui/main.qml respectively (and check whether that improves things)

While raster  is ok here (nvidia) i can (still ;-) confirm that plastik or other aurorae decorations with the native graphicssystem are unusably slow.

(In reply to comment #18)
> see comment #7 and edit
> /usr/share/apps/kwin/decorations/kwin4_decoration_qml_plastik/contents/ui/
> main.qml respectively (and check whether that improves things)

Yes, that helped a lot. But it still takes ~ half a second (with raster, desktop effects disabled).
 I decided to keep desktop effects on and switch to the "glowglass-lite-black" theme.

I am seeing similar effects as described in comment #15. I applied the (inverse) patch from comment #8 and, independently, toggled between native and raster rendering. In my case, it does not make much of a difference. The desktop cant be used like this, it is just too slow and non-responsive for a second or two when changing windows. 

I am testing with openSUSE 12.3 rc2, both inside VirtualBox and on physical hardware. In the latter case, it's running on an ATI X1400 graphics card powered by the corresponding opensource driver. (The CPU is a Core2Duo T5600 @ 1.83 GHz.)

Today I pushed some changes to kwin master which should significantly improve this situation. For OpenGL there should not be any overhead inside KWin when rendering the decoration with raster or native: they use the same code path. Also for XRender/raster there should be some improvements.

What doesn't change is the fact that QML doesn't like the native interface. Just don't do it. The only thing we can do in KWin is to enforce raster if one switches to a QML decoration. But I don't think it's worth to write the code given that we get that for free with Qt 5.

Can you point me to the appropriate (git) repository and branch? I would like to look into this. 

It appears to me that the major performance issue in my case is caused by the colour animation of the titlebar (loss / regain of focus). No matter what I hack into those QML/XML files etc, I just cant deactivate it. Ironically, it causes a rather high CPU load, which is wired. I am under the impression, that whatever parses those files, does not respect those parameters. 

Going slightly off-topic here, but the mentioned QML files do not contain a "full definition" of the (plastik) window decoration, do they? Where can I find (the source code of) the other bits and pieces in their latest state (KDE 4.10)?

kde-workspace, master branch
However this will NOT affect the uncomposited case.

To deactivate animations, ensure that the duration values are set to 0 in
/usr/share/apps/kwin/decorations/kwin4_decoration_qml_plastik/contents/ui/main.qml and animateButtons is set to zero as well.

If speed is inacceptable, use the "laptop" decoration, which should work fine (on the native graphicssystem)

ps: https://projects.kde.org/projects/kde/kde-workspace/repository

Git commit 08fce80bd0bba1a653406f5acfd9cf6a6149eb95 by Martin Gräßlin.
Committed on 12/03/2013 at 18:36.
Pushed by graesslin into branch 'KDE/4.10'.

Disable animations in Plastik for native or non-compositing

Adding a new property on whether we want animations based on whether we
are on raster or with Compositing. The property is constant as the deco
gets recreated on compositing change state anyway.

REVIEW: 109456
FIXED-IN: 4.10.2

M  +13   -0    kwin/clients/aurorae/src/aurorae.cpp
M  +3    -0    kwin/clients/aurorae/src/aurorae.h
M  +4    -1    kwin/clients/aurorae/themes/plastik/package/contents/ui/main.qml

http://commits.kde.org/kde-workspace/08fce80bd0bba1a653406f5acfd9cf6a6149eb95

The text placement issue that the original bug reporter also mentioned (and included in his patches) seems as if it would remain an issue.  Window title text is crammed at the top of the titlebar.  He added a topMargin of 3, but I found that setting a topMargin of 2 makes my titlebars look identical to KDE 4.9's Plastik.  Not sure if that is the "correct" solution, though?  Should a separate bug be opened?

If the demand is to get the title vertically centered (to a particular other object), the solution is to set it like this and not add a random margin - that will always somehow fail.

And yes, would be different bug/wish (can't was what plastik was like back then)