Announcement

Collapse
No announcement yet.

Are Compositing Window Managers Lightweight?

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

  • #21
    Moving windows around was perfect scenario for composited WM, and yet it didn't go that well (on nvidia at least). Here's example, why I'm not using compositing, even on quite fast hardware (2500k/GTX 570) - sluggishness.

    Comment


    • #22
      Originally posted by Awesomeness View Post
      Why are you asking such stupid questions? Of course I already tried it and I know for a fact that I'm right.
      You are obviously a liar, others HAVE posted tests, and the results support truth, that you are wrong.

      Comment


      • #23
        Originally posted by Awesomeness View Post
        As I wrote: My PC in ancient, so the difference is more drastic.

        The ones who advertise that GL compositing is bad, probably own relatively new PCs with many CPU cores and only think they know what's better for lower-end hardware. The fact is that the older a PC is, the more help its CPU needs from the GPU.
        Fact remains that compositing does NOT help the CPU. It loads the CPU with more irrelevant crap that doesn't need to be done at all.

        Comment


        • #24
          Originally posted by gedgon View Post
          Moving windows around was perfect scenario for composited WM, and yet it didn't go that well (on nvidia at least). Here's example, why I'm not using compositing, even on quite fast hardware (2500k/GTX 570) - sluggishness.

          And there we have it... compositing, aka "TURD".
          ... one of the reasons I'm using MATE DE. Its actually *fast* and easy on the CPU. Even when I have 50 or 100 windows open. Try that with compositing and see a high end multi-core anything with any GPU grind close to a halt.

          Comment


          • #25
            I see a lot of silly posts here that just blindly hate on any form of composting. To those people, it should be noted that X is horrifically inefficient at compositing (X simply was not designed with it in mind), and X adds a lot of inefficient IPC to compositing. This will be addressed with wayland. With wayland compositing is much more "direct to the hardware" without an inefficient middleman like X in the way. I recommend watching this: http://www.youtube.com/watch?v=RIctzAQOe44 which explains how horrible X is for modern scenarios like compositing. these days drivers and compositors just try to avoid going through X as much as possible because its so inefficient. DRI3 will continue this trend and should give compositing with X a nice boost before wayland comes.

            It should also be noted that some modern hardware is literally designed with a compositor in mind, the biggest example being intel graphics sandybridge or newer. To properly achieve vsync with this hardware a compositor that does page-flipping is required, and a page-flipping compositor is the only way to get vsync while letting the card go into its power-saving state. I absolutely can't stand using a desktop that tears when I'm watching videos, so for me a compositor is 100% necessary low performance or not (yes I'm aware I can use mplayer with gl output, but there's problems with that, for some reason it refuses to remove tearing for 4:3 videos (I get tearing all the way from top to bottom), but 16:9 videos play fine tear-free with mplayer gl output, very strange :/ There's also some software that doesn't support gl output at all, like flash, and not all video players support it either.) With a proper compositor I can guarantee that I don't get annoying issues like video tearing. Tearing in vidoes isn't the only issue either, without a compositor scrolling in firefox is super ugly for example, lots of visible tearing when scrolling up and down, honestly I don't know how anyone can stand that

            In any case, as least in my experience with DRI2, decent drivers, and a good compositor manages to work around X's awfulness reasonably well and provide decent compositing performance. I haven't had any problems with high cpu usage or performance with many windows on my crappy intel hd4000 graphics... Compositong on linux has reached "acceptable" (but not yet ideal) performance, and will improve hugely in the future with wayland, and I agree with the article in that compositing doesn't necessarily make a desktop "not lightweight". For example I use XFCE with compton for tear-free compositing and the desktop is still extremely snappy and responsive, I didn't notice any performance decrease after adding opengl compositing, in some cases things were actually much smoother (scrolling in firefox).
            Last edited by bwat47; 02 May 2013, 09:37 AM.

            Comment


            • #26
              Originally posted by bwat47 View Post
              I see a lot of silly posts here that just blindly hate on any form of composting. To those people, it should be noted that X is horrifically inefficient at compositing (X simply was not designed with it in mind), and X adds a lot of inefficient IPC to compositing. This will be addressed with wayland. With wayland compositing is much more "direct to the hardware" without an inefficient middleman like X in the way. I recommend watching this: http://www.youtube.com/watch?v=RIctzAQOe44 which explains how horrible X is for modern scenarios like compositing.
              I agree with you, and I hope Wayland will change everything, but it isn't here yet (at least it isn't usable), and correct me if I'm wrong, Martin isn't talking about future 'lightweight' KWin compositing?

              Comment


              • #27
                Originally posted by ultimA View Post
                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.
                /+1 For a very informative post.
                People tend to underestimate the price, both in CPU time and (especially) latency attached to bus transfers.
                Sure, any modern GPU can run circles around CPU when it comes to shuffling pixels around, however, getting the information to the GPU isn't cheap.

                *However*, composite vs. non-composing WM debate is far more complex than what the posts here seem to suggests.
                *Alot* is dependent on the GPU HW, bus speed, memory, driver type (binary vs. open) and the screen resolution.
                E.g. icewm is noticeably faster than kwin + effects on a QC-AMD+GF212+nVidia-binary+24"HD. However, on my other workstation (2xXeon+GF470+nVidia-binary+27"QHD) the situation is reversed with kwin beating the crap out of icewm.

                Now, please notice that I'm not comparing CPU usage but actual (user-perceived) performance / responsiveness.

                - Gilboa
                Last edited by gilboa; 02 May 2013, 10:08 AM.
                oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
                oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
                oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
                Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

                Comment


                • #28
                  Originally posted by bwat47 View Post
                  It should also be noted that some modern hardware is literally designed with a compositor in mind, the biggest example being intel graphics sandybridge or newer.
                  That's one of the reasons why i think the kwin developer post is pointless. Over the years , hardware is now more efficient and specialized (for instance, compositing), drivers are better, Xorg is better, so i don't know how his work with kwin is relevant at all. I don't think that he even bothers to test kwin in other machines other that his own.

                  You acknowledge that not all hardware is designed to work with compositing, the sandybridge is still a recent hardware. Assumptions are made about the hardware and the drivers, but this is not Apple where hardware and software are in perfect sync.

                  So even today, compositing doesn't always works, sometimes is worse (some people is forced to use xrender), sometimes doesn't works as it should due bad driver and hardware detection and the user is forced to use xrender. Sometimes works, but there's no real improvement regarding battery, memory or CPU utilization. Other times works.

                  That developer is trying to make a point, that lightweight doesn't exist, but his arguments are not only fuzzy but misleading too. You can guess that he just want to justify his lack of interest about performance optimization and he just want to spend more time playing with goodies and features.


                  In paper, compositing and GPU is the way to go, and in fact is getting better. But we live in the real world, where paper burns.

                  Comment


                  • #29
                    Originally posted by droidhacker View Post
                    You are obviously a liar, others HAVE posted tests, and the results support truth, that you are wrong.
                    Hey asshole, ever considered that some people do not always have fast internet access?

                    Here's with compositing: http://www.mediafire.com/?2eswa4xatolexxh
                    And here's without compositing: http://www.mediafire.com/?i1q6yjmw93150nn

                    Comment


                    • #30
                      Originally posted by bwat47 View Post
                      For example I use XFCE with compton for tear-free compositing and the desktop is still extremely snappy and responsive, I didn't notice any performance decrease after adding opengl compositing, in some cases things were actually much smoother (scrolling in firefox).
                      Hi bwat47, would you mind providing your Compton command-line? Or is it just the typical example provided in say, the Arch wiki?

                      I'm using DWM in Arch, with no compositing currently. Mostly things run well, VLC and Mplayer utilize vdpau and I don't see any tearing but yes when it comes to Youtube of course.... or scrolling in Firefox, tearing is fairly noticeable.

                      I wouldn't mind trying Compton again but I've always worried about stability with it, but it's probably improved by now.

                      Comment

                      Working...
                      X