Announcement

Collapse
No announcement yet.

KWin Now Supports Suspended Compositing

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

  • #31
    Originally posted by BlackStar View Post
    On the contrary, basic desktop usability is greatly increased through the use of compositing. Shadows, overlays, window thumbnails, all help you navigate faster.
    Or you can use a tiling WM and not need to navigate, because everything is there in front of you all the time.

    /begin religious war over WMs

    Comment


    • #32
      I couldn't tell from the article, but if I'm running a windowed OpenGL application like say Doom 3 or OilRush would it disable compositing for me? I really prefer to not play games fullscreen especially on Linux.
      Since I have two screens, I've had too many problems where fullscreen games would stretch across both screens, so I'm always using windowed mode.

      Comment


      • #33
        Originally posted by mrugiero View Post
        Several reasons:
        1. You might not have a good GPU.
        2. You might not WANT a good GPU, if you use the computer just for work.
        In that case KWin does not activate compositing anyway.

        Originally posted by mrugiero View Post
        3. You might have a good GPU, but really "don't give a fuck" if you can see a shadow, a transparency or FX.
        So? Compositing and desktop effects are two completely different things. Nobody is forced to enable effects in KWin when compositing is enabled.

        Originally posted by mrugiero View Post
        Maybe you want it to be as fast as it can be, and you don't want compositor to take resources.
        WTF? Do you have any proof that KWin with compositing takes more resources than KWin without it?
        If anything, the system should run smoother and (in case of mobile devices) require less battery because the CPU renders less.

        Comment


        • #34
          Originally posted by deanjo View Post
          Because for the most part it is useless and serves no practical purpose.
          Lower CPU utilization and with it lower battery draining is a real benefit of compositing (no effects need to be active).

          Comment


          • #35
            Originally posted by Awesomeness View Post
            Lower CPU utilization and with it lower battery draining is a real benefit of compositing (no effects need to be active).
            GPU takes power as well. Feel free to post the links to the benchmarks showing compositing extending battery life.

            Comment


            • #36
              If the GPU still has 2d parts, it can likely shut down 3d parts when compositing is off.

              Comment


              • #37
                Originally posted by BlackStar View Post
                Shadows expose window relationships (active window, child windows). I find this singularly important - the non-composited gnome 2 desktop looks flat out confusing to my eyes.

                Overlays are important for things such as pop-up notifications. Do you recall how e.g. volume notifications used to look when running fullscreen apps or videos on non-composited desktops? (Extreme flickering and slowdowns everywhere). They also improve things such as window resizing (have you seen the new touch-aware resize overlay in Ubuntu/Unity?)

                Unfortunately, composition has acquired a bad reputation due to buggy drivers and an initial focus on bling rather than usability. This is unfortunate, since a modern desktop isn't conceivable without a compositor.
                First, I don't need to recall about it, I use openbox without compositor (basically, xcompmgr is too buggy, and my driver is too useless to be used with any other compositor). But that point is more about responsiveness than desktop navigation (in fact, if I'm using fullscreen video I'm actually not using the desktop itself).
                And, as much as I value that feature, I can not take advantage of it because I have no touchscreen (also, I don't use Unity :P), and that's my point after all: not everyone should want to use compositing. Anyway, I'm not sure if the GUI wich will be taken from KWin is the one wich makes one able to disactivate the compositor permanently (I mean, to not use it) or the one to dynamically disable it. If it is the second, my point goes nowhere, because noone is telling "you shall use composite" :P

                About the last two points, I agree that most of the bad fame of compositing is really buggy drivers and compositors, and bad priorities in the implementation, as I said before. But it's still not true the dependency on compositors to have a "modern" desktop for everyone, due to not being just one use.

                Comment


                • #38
                  Originally posted by pvtcupcakes View Post
                  I couldn't tell from the article, but if I'm running a windowed OpenGL application like say Doom 3 or OilRush would it disable compositing for me? I really prefer to not play games fullscreen especially on Linux.
                  Since I have two screens, I've had too many problems where fullscreen games would stretch across both screens, so I'm always using windowed mode.
                  I don't remember completely, but in another thread (one about wayland) someone said he use a different X server for each screen, that might help you with that problem.
                  But you probably would not move windows from a screen to another...

                  Comment


                  • #39
                    Originally posted by Awesomeness View Post
                    In that case KWin does not activate compositing anyway.


                    So? Compositing and desktop effects are two completely different things. Nobody is forced to enable effects in KWin when compositing is enabled.


                    WTF? Do you have any proof that KWin with compositing takes more resources than KWin without it?
                    If anything, the system should run smoother and (in case of mobile devices) require less battery because the CPU renders less.
                    I wasn't talking about the specific KWin case, but in general. In fact, I can't care less about what the devs do with KWin, as far as I don't use KDE.
                    As someone said, the GPU uses power too. Also, the tech itself is more resources consuming (not necessarily from the CPU), because it uses different buffers for the windows, and operates with them independently if they are in front.
                    Also, the effects itself are not the biggest problem, yes they are more operations, but the main problem I see is the GPU or even the CPU (KWin probably uses only if it can use the GPU, but, as I said, I'm talking in general, and for example xcompmgr can work just with CPU) has to work with all the windows, independently if they are background (it might not be a problem with two or three windows, though).

                    Comment


                    • #40
                      Originally posted by mrugiero View Post
                      I wasn't talking about the specific KWin case, but in general. In fact, I can't care less about what the devs do with KWin, as far as I don't use KDE.
                      As someone said, the GPU uses power too. Also, the tech itself is more resources consuming (not necessarily from the CPU), because it uses different buffers for the windows, and operates with them independently if they are in front.
                      Also, the effects itself are not the biggest problem, yes they are more operations, but the main problem I see is the GPU or even the CPU (KWin probably uses only if it can use the GPU, but, as I said, I'm talking in general, and for example xcompmgr can work just with CPU) has to work with all the windows, independently if they are background (it might not be a problem with two or three windows, though).
                      Things are not nearly as clear-cut as you make them. By working with each window independently, the compositor can reduce CPU usage when moving windows around. Without a compositor, you need to repaint each window as it is gradually uncovered. With a compositor, you can simply blit the persisted window contents to the backbuffer.

                      Originally posted by randomizer
                      Or you can use a tiling WM and not need to navigate, because everything is there in front of you all the time.

                      /begin religious war over WMs
                      I have tried this but it tiling just didn't appeal to me. The window layout tended to be suboptimal until I corrected it manually. If I have to move windows manually, I might as well do away with the tiling manager completely.

                      Comment

                      Working...
                      X