Announcement

Collapse
No announcement yet.

KWin-LowLatency: An Effort To Yield Less Stutter & Lower Latency With The KDE Desktop

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

  • #81
    Originally posted by debianxfce View Post
    You should prove that when Randr is none, it activates tearfree in the xf86-video-amdgpu driver. Because you are not a developer, you can not post link to a code line line that proves your point.
    Originally posted by debianxfce View Post
    I see tearing with this: https://www.testufo.com/stutter
    Invalid test. This test on Linux disable tearing controls. Application level tearing you can force by turning different features off.

    Originally posted by debianxfce View Post
    So tearfree is not enabled in the xf86-video-amdgpu driver when it is auto. The video is tear free when enabling the xfce compositor.
    The test you pointed to will look just teared the same with the xfce compositor on or off. I am a xfce desktop user.

    Really I am said I am a support person. This means I don't need to put up the source. You are claiming to be a software developer so please show me the exact lines of code. Support person has to know what tests are total bogus. You know less than a support person.

    I may not be a developer with wine. But does not mean I am not a Software developer on other things.

    Comment


    • #82
      Originally posted by tildearrow View Post
      Really? I thought you couldn't have a sync object for the VBlank interval...
      You can but inside the GPU only.

      Originally posted by tildearrow View Post
      But actually, what I mean is a method to wait for VBlank without swapping buffers.
      This is a horrible no you cannot from the CPU this is not a Linux/Wayland/X11 limitation this is a GPU designed in limitation.
      GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.

      This protocol is done this way it is because this is the GPU limitation.

      Presentation time is exploiting the fact you can get the time a buffer was in fact displayed.


      Looking though the weston implementation of presentation time will be use to you.

      This is where you start hating dynamic vsync rate. Fixed vsync you can by tracking when the buffers present and aligning you timer events based off that feedback you can choose to wait for vsync to pass. Dynamic is a pure ass.

      This limitation of not being able to in fact wait for a vsync on the cpu side is true under x.org without wayland as well. This is just how the opengl/vuklan/gpu are.

      Comment


      • #83
        I just installed it. It's great. Using nvidia binrary driver. No hiccups and frame drops anymore when playing video. Less latency too. This is how KWin should always have been. It is some serious improvement over vanilla KWin.

        Comment


        • #84
          Originally posted by debianxfce View Post
          Vote with your package manager and install the Xfce desktop. KDE is never ready and the KDE desktop is schizophrenic compared to simple,freely configurable, stable, light and fast Xfce.
          I tried all desktop environments. All had problems. XFCE's is its inability to make use of modern, high refresh rate displays:



          It seems it's worse than vanilla KWin. It also doesn't sync its compositing loop with the monitor's vsync but instead applies an unsynced frame limit, which results in frame drops and stutter. And in this case, that unsynced frame cap seems fixed to 60FPS.

          This is NOT how you do compositing. macOS and Windows do it right. This KWin fork seems to finally get it right.
          Last edited by RealNC; 21 May 2019, 05:16 AM.

          Comment


          • #85
            Originally posted by debianxfce View Post
            Xfce works fine without the compositor as you wrote. Compositors slow down performance, so disable them in gaming computers that you have too.
            I'm not playing games in Linux anymore (I dual boot into my Wintendo 10 install for that, which is the only thing it's good for.) I use my Linux install for work and multimedia, and I don't want it to feel like it's from 1995. I'm afraid disabling compositing for me in 2019 is completely and utterly out of the question.

            In any event, this KWin fork actually solved ALL my issues :-) Perfectly smooth, no stutter or frame skips, no lag. So it's not like I have to switch to something different anymore.
            Last edited by RealNC; 22 May 2019, 06:33 AM.

            Comment


            • #86
              Originally posted by debianxfce View Post
              So you do not need the 120Hz refresh rate in Linux. 60Hz is fine for everything for most of the people. Freesync and LFC is for preventing tearing and no need to buy expensive high refresh rate monitors.
              120Hz is not only useful for games. The desktop itself sees a huge improvement. Once you used a 120Hz desktop, 60Hz compares extremely poorly. Everything is blurry when it moves and feels sluggish and stuttery, be it scrolling in web pages and documents, desktop effect animations or moving a window on the desktop. There's just no comparison. If you haven't used a 120Hz desktop yourself, you can't really understand.

              Also, the attitude of "60Hz is fine for most people" is, frankly, annoying. If 60Hz is fine for you, then I'm afraid your standards are too low. I've been using high refresh rate monitors since the 90s. 60Hz never was, and never will be "fine." It's only fine if you never actually had anything better.

              Comment

              Working...
              X