Page 1 of 4 123 ... LastLast
Results 1 to 10 of 32

Thread: Are Compositing Window Managers Lightweight?

  1. #1
    Join Date
    Jan 2007
    Posts
    14,621

    Default Are Compositing Window Managers Lightweight?

    Phoronix: Are Compositing Window Managers Lightweight?

    With the recent talk about developing a lightweight KDE desktop, the KWin maintainer, Martin Grlin, is talking out to try to clarify whether the compositing window manager is lightweight...

    http://www.phoronix.com/vr.php?view=MTM2MjY

  2. #2
    Join Date
    Mar 2012
    Posts
    240

    Default

    You should make some benchmarks to compare with his claims. (Like kwin being the most efficient and lightweight WM ?)

  3. #3
    Join Date
    Oct 2009
    Posts
    2,086

    Default

    Quote Originally Posted by phoronix View Post
    Phoronix: Are Compositing Window Managers Lightweight?

    With the recent talk about developing a lightweight KDE desktop, the KWin maintainer, Martin Grlin, is talking out to try to clarify whether the compositing window manager is lightweight...

    http://www.phoronix.com/vr.php?view=MTM2MjY
    Until someone actually shows me a compositing window manager that uses less CPU than conventional, I call B.S.
    Sure.. in *theory*, if you offload everything to the GPU, that means less CPU. In *practice*, it takes more CPU just to send everything over to the GPU than to just process it.

  4. #4
    Join Date
    Jul 2009
    Posts
    221

    Default

    Who cares?

    I read through Martin's previous post a bit and it seems to me that the problem is more that some distributions of the KDE desktop don't work well on some hardware, and a certain problem agreeing on what exactly "KDE" is (other than a community).

  5. #5
    Join Date
    Dec 2010
    Posts
    1,120

    Default

    Quote Originally Posted by droidhacker View Post
    Until someone actually shows me a compositing window manager that uses less CPU than conventional, I call B.S.
    Sure.. in *theory*, if you offload everything to the GPU, that means less CPU. In *practice*, it takes more CPU just to send everything over to the GPU than to just process it.
    Bullshit. The simply action of moving windows takes up next to zero CPU time with GL compositing. Without compositing it can be very CPU consuming, esp. when the window is big.
    Anybody can just open a CPU monitor and check for himself.

  6. #6
    Join Date
    Aug 2012
    Location
    Europe/Moscow
    Posts
    167

  7. #7
    Join Date
    Mar 2013
    Posts
    144

    Default

    Quote Originally Posted by Awesomeness View Post
    Bullshit. The simply action of moving windows takes up next to zero CPU time with GL compositing. Without compositing it can be very CPU consuming, esp. when the window is big.
    Anybody can just open a CPU monitor and check for himself.
    There's at least memory bandwidth and power usage considerations in that equation that merit benchmarking. For instance, I've seen dedicated 300$ graphics card preform worse in 2D composition than a 5$ Mali 400 SoC core (guesstimating that number...) and not because of bad drivers. Just different usage scenarios.

    The Nvidia Optimus is a good example of how these complex, interwoven systems with their complex drivers need thorough benchmarking in a non trivial "zero CPU time with GL compositing" way. Throw in some video encoding\decoding, networking or even OpenCL and you get some surprises to be sure.

  8. #8
    Join Date
    Oct 2009
    Posts
    2,086

    Default

    Quote Originally Posted by Awesomeness View Post
    Bullshit. The simply action of moving windows takes up next to zero CPU time with GL compositing. Without compositing it can be very CPU consuming, esp. when the window is big.
    Anybody can just open a CPU monitor and check for himself.
    Have you tried yet? Go ahead and try it!!!!

    You couldn't be more wrong.

  9. #9
    Join Date
    Nov 2012
    Location
    France
    Posts
    563

    Default

    Quote Originally Posted by droidhacker View Post
    Have you tried yet? Go ahead and try it!!!!

    You couldn't be more wrong.
    It does decrease CPU and power usage. My netbook's battery life is better with compositing enabled on Xubuntu 12.10.

  10. #10
    Join Date
    Jul 2011
    Posts
    44

    Default

    Everybody seems to forget that when people look for something "lightweight", their true goal is rarely to "minimize CPU usage" or to "minimize memory usage". CPU and mem usage are just indirect indicators of qualities that are much harder to measure objectively/accurately but are in correlation with CPU and mem: response time and battery time. Responsiveness and longer battery times are the what users really want. The linked article makes a single but fatal flaw, in that it argues that compositing is just a memory/cpu tradeoff, but it forgets that users actually want a more responsive and more power-efficient system and that these do not only depend on the CPU and memory.

    I have a long experience in 3D game programming, and here is a fact that I can tell you about. Data transfers between CPU and GPU are bad, coz they are inherently slow. This is the sole reason that in the early days of 3D, screen-space effects (like blurs), environmental mapping (used for reflections and mirrors) and many other effects were used rarely: they were extremely slow because data had to be downloaded from the GPU to CPU and then back to the GPU, which used to be slow.

    What does this mean for compositing? Sure, with OpenGL compositing the CPU can sleep more and the GPU can work more power-efficiently on the pixels than the CPU could. But bus transfer times can seriously limit responsiveness on old hardware or crappy drivers, for the same reason that on old hardware such effects killed your FPS from 40 to 5 in games. Coz (and correct me if I'm wrong, I'm not an expert on x11 and internals of GUI toolkits), I'm reasonably sure that GTK and classic Qt render most of their stuff on the CPU. So any time an application changes its window contents, data has to be sent over to the GPU from the CPU, possibly killing your compositing framerate.

    I know, I've been talking about older hardware, so does this have any relevance today? It could. For games, said issues have been solved to some extent: data exchange between CPU and GPU is still bad, but games can use such effects more freely now, because 1) graphics buses have gotten faster, 2) GPU hardware and drivers implemented support of making textures out of GPU-rendered frames without having to download them to the CPU first, and 3) games started to use these driver features. For desktop compositing, since most rendering is done on the CPU, such "advanced" driver features cannot be used, which leaves us on the slow side. Not to mention, if your GPU driver falls back to CPU rendering for many things, then compositing is more likely than not a large and negative hit on performance. Otherwise, the effect on responsiveness will depend on the hardware, the quality of the drivers and the rendering mechanisms used by the GUI toolkit. Compositing is likely a win for the battery if your HW/driver is good enough though.

    What to take home, IMHO? This long post was merely intended to point out that the "lightweigthedness" of compositing is a much more complex issue than just CPU/memory trade-off, so the original article is very shallow, pointless and I could say even misleading. Compositing could equally slow down or speed up your system based on many factors, and it might not even have anything to do with CPU or memory. So here is what you should do if you are concerned about the question of compositing efficiency on *your* system: Try it out, and if by experience you feel it slows down your system, turn it off. Otherwise, leave it on.
    Last edited by ultimA; 05-01-2013 at 04:41 PM.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •