Bug 314532 - Plastik (QML) decoration: poor performance with desktop effects
Summary: Plastik (QML) decoration: poor performance with desktop effects
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: decorations (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal with 2 votes (vote)
Target Milestone: 4.10.2
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-06 16:27 UTC by dev.dliw
Modified: 2013-03-22 14:29 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.10.2


Attachments
Screenshot of the performance overlay (5.61 KB, image/png)
2013-02-06 16:30 UTC, dev.dliw
Details
Patch for main.qml (1.50 KB, patch)
2013-02-06 20:20 UTC, dev.dliw
Details
New patch (2.09 KB, patch)
2013-02-07 16:26 UTC, dev.dliw
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dev.dliw 2013-02-06 16:27:20 UTC
Default Plastik decoration (don't know exactly if it's the QML version, but it should be) has very poor performance if desktop effects are turned on.

The performance overlay shows constant 60 FPS most of the time, but with every desktop effect there is a big spike in the graph and FPS drop under 30 and then slowly increase again.
Any other decoration runs smoothly (=60 FPS) all the time regardless of desktop effects.

Desktop effects are set to use native OpenGL 2.0.

Reproducible: Always

Steps to Reproduce:
1. Activate Plastik window decoration
2. Activate desktop effects
3. Minimize / maximize windows



Running KDE 4.10 on openSUSE 12.2
RPM packages from
http://download.opensuse.org/repositories/KDE:/Extra/KDE_Release_410_openSUSE_12.2/
Comment 1 dev.dliw 2013-02-06 16:30:21 UTC
Created attachment 76947 [details]
Screenshot of the performance overlay

The graph after launching krunner with <Alt><F2>...
Comment 2 Thomas Lübking 2013-02-06 17:19:52 UTC
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.
Comment 3 dev.dliw 2013-02-06 20:18:49 UTC
Support information:
http://paste.kde.org/666356/
Comment 4 dev.dliw 2013-02-06 20:20:04 UTC
Created attachment 76956 [details]
Patch for main.qml
Comment 5 dev.dliw 2013-02-06 20:29:50 UTC
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.
Comment 6 Thomas Lübking 2013-02-06 20:57:53 UTC
> 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.
Comment 7 Martin Flöser 2013-02-06 21:10:42 UTC
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.
Comment 8 dev.dliw 2013-02-07 16:26:11 UTC
Created attachment 76983 [details]
New patch
Comment 9 Martin Flöser 2013-02-07 16:35:20 UTC
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.
Comment 10 dev.dliw 2013-02-07 16:57:52 UTC
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
Comment 11 dev.dliw 2013-02-07 17:03:42 UTC
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
Comment 12 dev.dliw 2013-02-07 17:08:03 UTC
>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.
Comment 13 Thomas Lübking 2013-02-07 17:08:47 UTC
(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)
Comment 14 Martin Flöser 2013-02-07 19:30:11 UTC
> 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
Comment 15 Benni Hill 2013-02-08 18:05:48 UTC
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?
Comment 16 Thomas Lübking 2013-02-08 18:11:53 UTC
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.
Comment 17 Benni Hill 2013-02-08 19:11:27 UTC
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.
Comment 18 Thomas Lübking 2013-02-08 21:01:01 UTC
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.
Comment 19 Benni Hill 2013-02-11 10:45:05 UTC
(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.
Comment 20 SME 2013-03-11 15:35:20 UTC
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.)
Comment 21 Martin Flöser 2013-03-11 16:08:51 UTC
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.
Comment 22 SME 2013-03-11 17:06:05 UTC
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)?
Comment 23 Thomas Lübking 2013-03-11 17:48:27 UTC
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)
Comment 25 Martin Flöser 2013-03-13 07:07:23 UTC
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
Comment 26 Bob Farmer 2013-03-22 14:06:28 UTC
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?
Comment 27 Thomas Lübking 2013-03-22 14:29:09 UTC
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)