For the usage of KWin in Plasma Active many of KWin’s advanced features are just not needed. For example on Plasma Active we target OpenGL ES/EGL compositing, so the for desktop usage still useful XRender compositing is just unneccessary bloat added to the binary.
In 4.7 we started to add some build-options to remove unused parts from the build. We decided that on Plasma Active we do not need window decorations and added an option to exclude the decorations from the build and the basic functionality to start KWin without any decoration plugin present (which was not possible before).
Now with master open and a GSoC working on modularizing KWin, we were able to split out more stuff which can be disabled at compile time. There is a new build option to group all the settings for KWin on Plasma Active which currently includes:
- No window decorations
- No configuration modules
- Reduced set of effects
- No Alt+Tab (window switching)
- No Screenedge interaction
- No XRender Compositing
- Default build to OpenGL ES if available at compile time
Some of the removed parts also affect the size of the KWin binary and/or the KWin internal libraries. I was interested in the differences of size when building KWin for desktop and for Plasma Active. So today I did a release build of current master with “normal” build flags and with the active build flag and compared the size of:
- kwin.so
- kwin_effects_builtins
- libkdecorations
- libkwineffects
- oxygen decoration
For the desktop this sums up here on my system to 3239.5 KB and for active it’s only 1987.3 KB. And this is without considering the size of the installed package where the difference is much bigger as we do not install any decorations and configuration modules on Active. I’m really quite impressed seeing that the size of KWin is so much decreased. The biggest impact has the removal of some desktop effects: the size of kwin_effects_builtins goes from 927 KB to 269 KB. And there is more to go like disabling window tiling support, desktop change OSD and so on and so on…
I hope to get some “real” numbers on comparing the package size once both builds based on master are available as a package.
=-=-=-=-=
Powered by Blogilo
“Stripping Down KWin…”
Can I watch?!
Seriously, this sounds great. You know what might be a wonderful idea: With all of these Ubuntu builds for Android devices, someone should build some Kubuntu ones with Plasma Active and Contour on board!
I’d assume it also brings the RAM usage down a bit as well (if for no other reason because the program being loaded into the RAM is smaller and has less features by default.) Without being terribly familiar with the architecture of KWin, I couldn’t begin to make any more assumptions in that area 🙂 Anyways, sounds like great/promising work so far!
Yes I also assume that it reduces RAM usage, but I have not tested in any way and there is probably no easy way to test, so I won’t test it 😉
RAM usage comes from either code or data. The amount of code is obviously reduced by removing unneeded features. The amount of data is also reduced (in general) because there is less code which generates data structures.¹
So yes, stripping unneeded features definitely reduces RAM usage.
¹The only exception to this rule is when missing data at one point is compensated by more complicated data structures and/or code at another point, but I assume this is not the case for our talented KWin developers.
This is critical work.
I fervently hope that you get beyond just turning off build switches,
and get to the meat of trimming dependencies the smart way.
Make, propose, and submit stubs upstream that consolidate or eliminate whole libraries.
I do so wish somebody would do this the the rest of KDE and figure out how to lose Akonadi.
sorry but exactly what dependency should I drop from an X11 window manager and compositor for KDE Plasma? Maybe X11 or OpenGL or KDELibs?
This sounds awesome, but I have an inverse question for you. Now that you’ve separated the XRender compositor in the build code, is there now a way to use it independently of KWin? My idea is to use it with XMonad, and other window managers that don’t have a compositor. Kinda like the role xcompmgr fills, but KDE-integrated and more powerful than just some pretty fades and shadows. 🙂
The KWin compositor is not yet separated form KWin Core.