Announcement

Collapse
No announcement yet.

Are Compositing Window Managers Lightweight?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    You should make some benchmarks to compare with his claims. (Like kwin being the most efficient and lightweight WM ?)

    Comment


    • #3
      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.

      Comment


      • #4
        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).

        Comment


        • #5
          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.

          Comment


          • #6
            No.
            http://en.wikipedia.org/wiki/Betteri...w_of_headlines

            Comment


            • #7
              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.

              Comment


              • #8
                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.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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, 04:41 PM.

                    Comment

                    Working...
                    X