Announcement

Collapse
No announcement yet.

KDE's KWin Compositor Sees Near Total Rewrite Of Compositing Code.

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

  • #31
    Hopefully this brings some much needed stability to the Wayland session as well. I mean the ability to reliably resize Xwayland windows or drag an image in Gwenview and not be kicked back to a login screen. Otherwise the Wayland session can be very nice.

    Comment


    • #32
      Originally posted by eydee View Post
      So why not just write it properly for the first time? People say the Linux world is full of duplicate work. This is the duplication of duplicate work.

      Comment


      • #33
        Originally posted by tildearrow View Post

        It means I would have to rename the thing to something like kwin-unredirect, and keep it up until they bring full-screen unredirection back...
        This patch implements direct scanout for fullscreen clients on the gbm backend. The main benefit of this is reduced latency and reduced resource usage for games and other...


        Isn't this essentially unredirection support?

        Comment


        • #34
          Originally posted by Baguy View Post

          This patch implements direct scanout for fullscreen clients on the gbm backend. The main benefit of this is reduced latency and reduced resource usage for games and other...


          Isn't this essentially unredirection support?
          Problem is that it is only for Wayland.

          Comment


          • #35
            Here's to hope for some stability finally in kwin compositing in multi-monitor without rebooting every few days after only 10 years or so.

            Comment


            • #36
              What about using Disman instead duplicating code again and again?

              Comment


              • #37
                Originally posted by vsteel View Post

                Two reasons.
                1. Because that is how open source works. If you feel that something needs changed you have the ability to do that. You might be lacking a programming skill or knowledge of the project but there is nothing in your way but you from learning and fixing what you think needs fixed. With a closed project, you don't have the ability to make changes no matter how simple.

                2. You can think of the open source projects like someone cooking a meal for you. They work hard in the kitchen to make you a seven course meal and you feel that it isn't quite up to your standards. [...]
                Also, as it was already written, there are other ways. For example, Edward Snowden recently asked for donations to the EFF (https://www.eff.org/deeplinks/2020/1...-broken-system), for Libreoffice you can use [crowdfunding](https://wiki.documentfoundation.org/Crowdfunding) to setup a bug bounty, etc.

                Comment


                • #38
                  Originally posted by chuckula View Post
                  Is this incorporating any code or general concepts from the Wayland KwinFT fork?

                  https://www.phoronix.com/scan.php?pa...DE-KWin-Forked
                  I think it's safe to assume Roman's work will never get back to upstream. The context of separation leaves very little hope that will ever happen.
                  I wonder what he will do now, kwin and kwinft codebases were already diverging fast, due to pretty high MR churn in upstream.
                  Should have swallowed his pride IMO

                  Comment


                  • #39
                    Originally posted by rabcor View Post
                    Now this is the kind of stuff that makes me tempted to give KDE another try, I remember having a lot of issues with it's compositor in the past, it being one of the key reasons why I could never stick with it.
                    You know you can use any window manager with Plasma Desktop at X environment, right?

                    Comment


                    • #40
                      Originally posted by zoomblab View Post
                      How is it proven that the rewrite is better in terms of achieving the stated outcomes and not regressing the maintainability of the code?

                      Honest question. I don't want to say that it doesn't deliver the promise. However, as it is known all or most programmers suffer from the reinvent/rewrite bug. We commonly think that our code is better. In most cases, it is a symptom of not understanding what and why the code was written in a certain way in the first place.
                      Simple answer, automated tests... If your codebase is covered with tests you can rewrite any part of it and make sure it behaves as expected.

                      Comment

                      Working...
                      X