Announcement

Collapse
No announcement yet.

KWinFT 5.20 With Aims For Better Wayland/X11 Experience Than KDE Plasma 5.20's KWin

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

  • #21
    Originally posted by romangg View Post
    That being said short-term improvements can also be important, a balance must be found, but in KDE such things just happen without coordination.
    If you can get the Fedora KDE team onboard I think that would be a big push for KWinFT.

    Comment


    • #22
      Originally posted by tildearrow View Post
      Stealing my job! I wonder whether they are going to add exclusive full-screen (unredirection) as well...
      Originally posted by romangg View Post
      Sadly there is so much to do.
      I haven't been keeping in the loop, so those two projects are unrelated and not at parity? Is there much point in continuing maintenance of the kwin-lowlatency project (assuming tildarrow still does), or are those improvements something KWinFT may eventually adopt when Roman has time? (or some community contributors help out)

      Is parity with upstream KWin going to remain, or is that going to be difficult with how the projects are diverging? It seems that from the discussions in this thread, there's already some parts that KWin in 5.20 does (while not so well yet) that KWinFT doesn't (yet).

      My main concern is with the amount of work to get done that Roman doesn't get burnt out and the project if not upstreamed gets stale preventing it from being usable in future Plasma updates? Does Roman have a Patreon or similar? (or is this work sponsored by some company?)

      Comment


      • #23
        romangg I may not understand fully the benefits of kwinft with regards to wrapland vs kwayland, but it seems you are using components or at least protocols out of wlroots? Is this correct? Does this mean we are more likely to see wlroots more advanced functionality (such as DRM Leasing) appear in kwinft/wrapland before kwin proper?

        Comment


        • #24
          Originally posted by polarathene View Post
          I haven't been keeping in the loop, so those two projects are unrelated and not at parity?
          You are kind of right.
          KWin-lowlatency closely follows upstream, while adding some patches on top.
          On the other hand KWinFT is a complete redesign that has pretty much parted away from upstream.

          Originally posted by polarathene View Post
          Is there much point in continuing maintenance of the kwin-lowlatency project (assuming tildarrow still does), or are those improvements something KWinFT may eventually adopt when Roman has time? (or some community contributors help out)
          I am trying hard to maintain it... but yes, there is.
          They will never bring full-screen unredirection back...

          Is this only because I am the worst developer in Phoronix?
          The last time they talked about my project and I commented on the matter, my comment got lost in the dust and was absolutely disliked; whereas Roman's comment somehow gets all the attention. How come?!

          Originally posted by polarathene View Post
          Is parity with upstream KWin going to remain, or is that going to be difficult with how the projects are diverging? It seems that from the discussions in this thread, there's already some parts that KWin in 5.20 does (while not so well yet) that KWinFT doesn't (yet).
          It is very doubtful... (as mentioned above)
          The patches should really be integrated into upstream soon, because if it diverges more it would just get more complicated...

          Originally posted by polarathene View Post
          My main concern is with the amount of work to get done that Roman doesn't get burnt out and the project if not upstreamed gets stale preventing it from being usable in future Plasma updates? Does Roman have a Patreon or similar? (or is this work sponsored by some company?)
          You know, it would be a completely dumb decision to not upstream the FT patches, considering how it solves several major issues with KWin (multi-monitor and stuttering), putting it on par with Mutter.
          Last edited by tildearrow; 16 October 2020, 02:58 PM.

          Comment


          • #25
            Originally posted by tildearrow View Post
            I am trying hard to maintain it... but yes, there is.
            I understand how maintenance can be a burden for such things. I did similar with a project for 1-2 years that was popular within it's small community, but the main devs while acknowledging it had little interest in addressing the issue I was patching (not exactly a bug, just a nice improvement). Was a repetitive process that didn't automate well, annoyingly the XML file parts also had various white-space/formatting inconsistencies (thankfully diff tools can ignore most of it). Someone ended up cloning my github repo and continuing the maintenance themselves (initially without any credit to my original project, attributing it all to themselves).

            Seems you did well though and have community packaging / distributing your updates

            Originally posted by tildearrow View Post
            They will never bring full-screen unredirection back...
            I can't recall too much about the advantages/disadvantages of such. You probably know whatever reasons they have for it are. My understanding is it bypasses compositor to get an increase in performance for fullscreen updates like gaming or media.

            I do remember years ago that in my multi-monitor setup, when I had something fullscreen like a game my other monitors output of the desktop didn't update, only if I alt-tabbed out from the active game on the other monitor. I think it was related to kwin trying to do some perf optimization by disabling compositing or something... was kind of annoying, but for a single monitor I suppose it'd make sense? (or perhaps with Wayland since each monitor is a different output it's a non-issue there?)

            Originally posted by tildearrow View Post
            Is this only because I am the worst developer in Phoronix?
            The last time they talked about my project and I commented on the matter, my comment got lost in the dust and was absolutely disliked; whereas Roman's comment somehow gets all the attention. How come?!
            I guess it's more to do with the scope of his project vs yours.

            Roman is also a more established/reputable developer within the community IIRC, and will get more news articles due to his blog and related projects around KWinFT? Perhaps you're not always recognized as the dev behind the kwin low-latency patch? (I was a bit surprised at first when I learned that fact lol), Phoronix community is also small, I wouldn't worry about it.

            That said, the quality of you as a developer has nothing to do with how much you or your projects get talked about imo. You both contribute value to your communities and that's all that really matters

            If you've got the skills to help out on KWinFT in some manner, perhaps Roman would welcome some assistance / contributions.


            Comment


            • #26
              Originally posted by romangg View Post
              I wouldn't call (the weekly KDE blog) "spam".
              That's because you're not a troll, unlike the person you responded to.

              Comment


              • #27
                Originally posted by 144Hz View Post
                shmerl Code can be re-merged but the communities will most likely stay fragmented. There’s really no way back. Roman claims KDE now puts marketing above engineering. (Hello Weekly blog spam and littering features on top of a broken architecture).
                Famous words of a 7-days per week forum troll.

                Comment


                • #28
                  Originally posted by simonsaysthis View Post

                  Famous words of a 7-days per week forum troll.
                  Exactly.
                  GOD is REAL unless declared as an INTEGER.

                  Comment


                  • #29
                    Originally posted by tildearrow View Post
                    They will never bring full-screen unredirection back...
                    Can you expand on that? If I think what it is, then fullscreen redirection is immensely helpful when there's need to as minimal input lag as possible (for example in some fast paced games), that means even forcefully disabling v-sync as that brings out most of the lag.
                    Where and when have kwin devs mentioned their issues with this?

                    Comment


                    • #30
                      Originally posted by JonnyRobbie View Post

                      Can you expand on that? If I think what it is, then fullscreen redirection is immensely helpful when there's need to as minimal input lag as possible (for example in some fast paced games), that means even forcefully disabling v-sync as that brings out most of the lag.
                      Where and when have kwin devs mentioned their issues with this?
                      Sure.

                      The purpose of full-screen unredirection is, indeed, reducing latency by letting a full-screen application bypass the compositor and paint directly to the screen.
                      This does not disable VSync. Instead, the application chooses whether to do VSync or not.

                      Their issues were mentioned years ago on this blog post:

                      Originally posted by mgraesslin
                      Removal of unredirect fullscreen windows

                      Unredirection of fullscreen windows has been a kind of blue-headed step child in KWin’s compositing infrastructure for a long time. It’s a feature not loved by the developers, not properly integrated, but you have to support it. For those not knowing the feature: it excludes an area from compositing and let’s the fullscreen window be rendered the normal way in X11 (unredirect). The idea is that you get slightly better performance if you bypass the compositor.

                      The functionality was never fully integrated into the compositor. It was way too easy to break out of the condition (e.g. a tooltip), but at the same time effects which should break it, had no way to do it (e.g. Present Windows should either not activate or end it). The weirdest oddity of the feature is that we had to hard disable it for all Intel drivers due to crashes. We don’t know whether this is still the case but after having had such a bad experience with it in the past, we decided to never turn it on again. Which means it’s a feature not even supported by all devices.

                      We developers did not spent much time on the feature as we think it doesn’t make much sense as KWin has a better infrastructure in place: blocking compositing. Applications are allowed to specify that compositing should be blocked. This results in KWin shutting down the compositor, freeing all resource related to it (e.g. destroying the OpenGL context), so all power to the running game. As the compositor is shutting down, you don’t have weird interactions like tooltips jumping out or effects not working properly.

                      There is a standardized way for applications to request this and we see that many games and applications (e.g. Kodi) make use of it. This is the preferred way in our opinion. Given that this mode is fully supported, we decided to remove unredirect fullscreen windows from KWin’s compositor. This streamlines our implementation and gives us one feature to concentrate on and make sure that it works exactly as our users need it. On Wayland the architecture looks different: there is no such thing like unredirect fullscreen, but we can ideally just pass the buffer to the DRM device. The idea is that we do the best optimized way whenever possible.
                      In a summary, in Plasma 5.8 they effectively removed the full-screen unredirection feature from KWin, because they considered the feature a "hack" with several "flaws" which also caused issues/crashes on Intel cards, and encouraged people to switch to their specific approach of disabling compositing ("block compositing")

                      However, the "block compositing" path has more flaws in my opinion:

                      ​​​​​​1. It is more of a hack than full-screen unredirection.
                      2. There is a delay when re-enabling compositing (say, if the application quits or you switch windows). It is very visible, and looks ugly. Full-screen unredirection does not have this issue.
                      3. You have to add support for this in your applications. Full-screen unredirection does this for you, without having to add any support.
                      4. Some applications (mostly ones based on SDL2) misbehave, and disable compositing even when windowed (which can get really annoying).
                      5. I actually never had a crash when using full-screen unredirection on my Intel laptop.

                      Comment

                      Working...
                      X