No announcement yet.

VRR, Lower Latency Likely Coming For KDE's KWin Wayland Compositor

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by oiaohm View Post
    Lot of people talk about high Hz monitors for game play you don't see many reviewers talking about how the high Hz monitors in a lot of cases result in better video play back for PAL encoded content due to how many 60Hz monitors the panel freq is really locked at 60Hz. Basically tildearrow its not just your phone with the 60Hz and bad PAL playback. PAL content playing back badly on monitors and TVs is horrible common as well and its going to become move common in lower end monitors/tv as chipsets do broad range clocking of panel keeps on disappearing being replaced by PSR work around to advertise 50Hz but then map 50 into 60hz.
    In fact this already happened. My 4K monitor from 2017 does not support 50Hz modes, and after adding one manually there was visible stutter every 1/10th of a second (which means it was mapping 50 into 60 as you described).
    The solution was to enable FreeSync (VRR)...


    • #32
      Originally posted by tildearrow View Post
      In fact this already happened. My 4K monitor from 2017 does not support 50Hz modes, and after adding one manually there was visible stutter every 1/10th of a second (which means it was mapping 50 into 60 as you described).
      The solution was to enable FreeSync (VRR)...
      If the panel is locked at 60Hz for PSR using FreeSync VRR all it does is randomise the stutter a bit. 50 to 60 results in needing 10 frames of duplicates.

      Fun of putting a flash 50 hz test on a screen. that when one frame is white and the next frame is black and measuring how long each black and white time frame is. Doing this with VRR enabled on monitored with panel locked to 60Hz sees that you have as much stutter per frame just it can be more even spread than the internal monitor controller implementation of 50 to 60.

      The first monitor/tv to appear using the PSR method was VRR was the first VRR monitor.

      tildearrow yes the disappearance of dynamically changing LCD clock speeds as been going on now for almost a decade. Yet people will still claim that VRR can do stuff that the fixed HZ of the LCD panel just will not allow. stutter/judder what ever you want to call it comes from this fixed clock. At best VRR will do on a fixed clock panel randomise stutter/judder making it less noticeable.

      Think about it 50 frames per second on a 60 frame per second panel means there has to be 10 duplicate frames so that gives the stutter every 1/10th of a second the size of a 1/60 of a second frame. 120 frames doing 50 frames per second gives 20 duplicates to be added in. So that every 1/20th of a second stutter the size of 1/120 of a second happens if everything is nice and evenly spread.

      Now the 50 frames into 60 Drop this back into 5 into 6 to make it simple. So you can be doing 1 2 3 4 5 5 to give you 6 as most simple LCD screen controllers do giving a repeating stutter exactly at 1/10th of a second that turns out to be really human noticiable. But this is not the only option 1 2 3 3 4 5 or 1 2 3 4 4 5.... to give you 6 and mix these in a kind of random pattern this is what enabling VRR end up doing on a fixed clock panel since the stutter is not always appearing at the same time comes less noticeable to human watcher. Yes the result of this tricks the human viewer into thinking the panel clock has changed to match VRR when in reality all that has happened that the stutter location has been randomised with the panel clock not changing at all.

      The freesync VRR on that tv is most likely still using the PSR mode for 50 into 60 on that TV. Just with more randomisation of the stutter point than when you push a pure 50Hz signal into it.


      • #33
        so it seems kwin changes made it to kde 5.21 in manjaro. there's an option to choose between latency and smoothess. with balanced... kde animations drop frames and stutter like crazy. what the hell were they thinking?

        when forcing it to smoothest (at the presumed cost of latency) it's slightly better, still drops a lot of frames but when something renders at 60fps - be it a game or youtube video in chromium - it's in general keeping that 60fps (i'm disabling compositing for fullscreen gaming and mpv anyway).

        i've checked it under wayland as well - that's why i've decided to go with "force smoothest" in general, since under wayland mpv dropped a frame from time to time on balanced, while with force smoothest it's almost perfect. almost... it can still drop a frame once every few minutes, which shouldn't happen and doesn't happen without compositing. added wayland bonuses: no caps-lock/ctrl mapping, gtk apps looking like crap, mouse cursor speed working differently, the list goes on.

        took a look at kwinft, saw the list of issues, gave up.

        for now i'm sticking to kde on x11, apps run smoothly, only kwin animations leave something to be desired, and for fullscreen use cases i can always disable compositing and ignore all this mess. still, if kde team manages to screw up kwin even more, i may consider trying out gnome 3, because this is ridiculous. i had smooth 60fps animations with kde+compiz decades ago, on geforce 4 mx ffs. this igpu can run crysis, yet kwin stutters at simple desktop slide-in effect? it's a bad joke.